Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 05 Apr 2007 12:16:43 +0900
From:      Jun Kuriyama <kuriyama@imgsrc.co.jp>
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:  <7mabxnfr38.wl%kuriyama@imgsrc.co.jp>
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
At Wed, 8 Mar 2006 19:57:22 -0500,
Kris Kennaway wrote:
> > 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.
> 
> 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:
> 
> 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

Interesting.  I just do little investigation.  Our daemon(8) locks a
file before fork(2), which makes NFS lock registration with svid(PID)
of daemon(8) process.

When above sleep(1) killed, this process has another PID than
daemon(8)'s, and request NFS unlock call with sleep(1)'s svid(PID).

Our rpc.lockd(8) refuses this request because of svid unmatch.

Which side should be fixed, daemon(8) and rpc.lockd(8)?


-- 
Jun Kuriyama <kuriyama@s2factory.co.jp> // S2 Factory, Inc.
               <kuriyama@imgsrc.co.jp> // IMG SRC, Inc.
               <kuriyama@FreeBSD.org> // FreeBSD Project



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7mabxnfr38.wl%kuriyama>