Date: Wed, 8 Mar 2006 21:03:54 -0500 From: Kris Kennaway <kris@obsecurity.org> To: Kris Kennaway <kris@obsecurity.org> Cc: kuriyama@imgsrc.co.jp, Miguel Lopes Santos Ramos <miguel@anjos.strangled.net>, freebsd-stable@freebsd.org Subject: Re: rpc.lockd brokenness (2) Message-ID: <20060309020354.GA56238@xor.obsecurity.org> In-Reply-To: <20060309005722.GA55432@xor.obsecurity.org> References: <20060308224531.GA53611@xor.obsecurity.org> <200603090026.k290Qihj002701@compaq.anjos.strangled.net> <20060309005722.GA55432@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 08, 2006 at 07:57:22PM -0500, Kris Kennaway wrote: > On Thu, Mar 09, 2006 at 12:26:44AM +0000, Miguel Lopes Santos Ramos wrote: > > > From: Kris Kennaway <kris@obsecurity.org> > > > Subject: Re: rpc.lockd brokenness (2) > > > > > > This is intentional. It's how pidfile_*() tests whether the process > > > is still running. The intention is that if someone tries to open the > > > pidfile again while the first process is still running, the lock > > > acquisition will fail and we'll know the other process is still alive, > > > and therefore avoid starting a second instance. > >=20 > > No, no, you got me wrong. The pidfile is left locked after cron stopped > > running (with /etc/rc.d/cron stop). This behaviour must be wrong. >=20 > OK, I misunderstood. The rc.d script will signal cron to kill it, > which should be closing the file descriptors and causing rpc.lockd to > release the lock. Perhaps this part is broken. OK, I tested this > with daemon -p, and it indeed seems to be broken: >=20 > haessal# daemon -p pid_file sleep 100000 > haessal# kill -KILL `cat pid_file` > haessal# ps -p `cat pid_file` > PID TT STAT TIME COMMAND > haessal# lockf -t 0 pid_file echo Yay > lockf: pid_file: already locked The bug is triggered because the file is locked in the parent (i.e. the daemon process, which creates the pidfile) but unlocked by the child after the fork (in this case, when the child is killed). On the server, rpc.lockd compares the svid (=3D pid of process on the client that is doing the lock call) of the lock and unlock requests, notices they're different and assumes that the unlock request is coming from some random process on the client that didn't hold the lock in the first place. In reality, the file descriptor was passed from parent to child by the fork(), and the child does actually hold the lock. Fixing this is probably hard (also: I can't see how this could have ever worked with pidfile locking in cron, since it always acquired the lock before forking, as now. Perhaps something else about your configuration changed.). Anyway, the workaround for you is probably not to use rpc.lockd on your NFS mounted /var (e.g. use mount_nfs -L). Since you don't have multiple machines accessing this filesystem (which wouldn't work anyway, as noted before), you don't need it anyway. Kris --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (FreeBSD) iD8DBQFED40JWry0BWjoQKURAtiHAKCSBS+69djSN0aujUWC9coD4HegXwCbBYC3 jb7m0Dpfo3I2LyoDc2Na71Y= =trIK -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060309020354.GA56238>