Date: Wed, 8 Mar 2006 21:22:36 -0500 From: Kris Kennaway <kris@obsecurity.org> To: Miguel Lopes Santos Ramos <miguel@anjos.strangled.net> Cc: kuriyama@imgsrc.co.jp, freebsd-stable@freebsd.org, kris@obsecurity.org Subject: Re: rpc.lockd brokenness (2) Message-ID: <20060309022236.GA56614@xor.obsecurity.org> In-Reply-To: <200603090214.k292ExSu003243@compaq.anjos.strangled.net> References: <20060309020354.GA56238@xor.obsecurity.org> <200603090214.k292ExSu003243@compaq.anjos.strangled.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 09, 2006 at 02:14:59AM +0000, Miguel Lopes Santos Ramos wrote: > > From: Kris Kennaway <kris@obsecurity.org> > > > > 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 (=3D3D 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. >=20 > Thank you. That is a very good explanation. I filed a PR, but I doubt this will be fixed any time soon since it'll need a lot of work. > > 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.). >=20 > Because the lock is somehow persisting through reboots, even though I=20 > stop nfslocking, remove /var/db/statd.status and restart it... Yeah, the file is still locked on the server, and will never be unlocked unless you stop and restart the rpc.lockd on the server (which releases all the locks it holds). > Oh yes, I must try that again. I had problems in the past with using the = -L > option, gnome didn't run. Probably it was because it was a single / files= ystem > mounted on boot and the option on fstab was ignored, I must try it again. You can use the -o lockd form in /etc/fstab. Kris --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (FreeBSD) iD8DBQFED5FsWry0BWjoQKURAqICAKCE5f0zjO0WTp4NiHXBjyeWdWVUbwCfRxst 95lZLSgKJsaerNZhW3MkcC4= =aKu5 -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060309022236.GA56614>