Date: Mon, 19 Sep 2005 11:48:35 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Jeremie Le Hen <jeremie@le-hen.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, Stefan Bethke <stb@lassitu.de>, cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libutil pidfile.3 Message-ID: <20050919114658.A95188@fledge.watson.org> In-Reply-To: <20050919091447.GL51142@obiwan.tataz.chchile.org> References: <200509161119.j8GBJcS0080866@repoman.freebsd.org> <BE56835D-58E2-4F21-B2CA-FB33ED18E382@lassitu.de> <20050919091447.GL51142@obiwan.tataz.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 19 Sep 2005, Jeremie Le Hen wrote: >>> FreeBSD src repository >>> >>> Modified files: >>> lib/libutil pidfile.3 >>> Log: >>> Pidfiles should be created with permission preventing users from >>> opening >>> them for reading. When user can open file for reading, he can also >>> flock(2) it, which can lead to confusions. >> >> This means that a monitoring tool would need to run with elevated >> privileges to determine the PID of the process to monitor, correct? > > I can't see what's the problem with disclosing daemons' PID to all > users, given they won't be able to signal it or such anyway. The problem isn't with revealing the pid, it's with allowing arbitrary access to the pidfile. Specifically, a malicious reader can open the file and acquire a lock on it, preventing the program or monitoring tools from acquiring a lock, which they try to do unconditionally as part of their activities. This is a hard-to-address issue, since sometimes you want locking to span users, and sometimes you don't. The only preventative measure, should one care enough, is to prevent untrusted parties from being able to open the file. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050919114658.A95188>