From owner-freebsd-bugs@FreeBSD.ORG Thu Mar 9 02:20:08 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE30216A420 for ; Thu, 9 Mar 2006 02:20:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5F1043D45 for ; Thu, 9 Mar 2006 02:20:06 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k292K6lu082802 for ; Thu, 9 Mar 2006 02:20:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k292K6jE082800; Thu, 9 Mar 2006 02:20:06 GMT (envelope-from gnats) Resent-Date: Thu, 9 Mar 2006 02:20:06 GMT Resent-Message-Id: <200603090220.k292K6jE082800@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Kris Kennaway Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1266616A422 for ; Thu, 9 Mar 2006 02:16:38 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B28643D53 for ; Thu, 9 Mar 2006 02:16:37 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 427111A4D89 for ; Wed, 8 Mar 2006 18:16:37 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 99CFB52058; Wed, 8 Mar 2006 21:16:36 -0500 (EST) Message-Id: <20060309021636.99CFB52058@obsecurity.dyndns.org> Date: Wed, 8 Mar 2006 21:16:36 -0500 (EST) From: Kris Kennaway To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: kern/94256: nfs locking/rpc.lockd doesn't understand file descriptor sharing X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kris Kennaway List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2006 02:20:09 -0000 >Number: 94256 >Category: kern >Synopsis: nfs locking/rpc.lockd doesn't understand file descriptor sharing >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Mar 09 02:20:06 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Kris Kennaway >Release: FreeBSD 6.0-STABLE i386 >Organization: FreeBSD >Environment: System: FreeBSD xor.obsecurity.org 6.0-STABLE FreeBSD 6.0-STABLE #13: Sun Nov 6 12:45:25 EST 2005 kkenn@xor.obsecurity.org:/mnt/src/sys/i386/compile/XOR i386 >Description: NFS locking uses an 'svid' field for indicating ownership of lock requests. In the FreeBSD implementation this is the pid of the process performing the lock request on the NFS client. The rpc.lockd server uses this field to decide whether a process requesting an unlock operation is holding a lock. i.e. it assumes that the pid that locks a file is the only process that can legitimately perform the corresponding unlock operation. This is false in a UNIX world, because file descriptors may be passed between processes. For example, a process may lock a file, fork, and the child process inherits the file descriptor table and may legitimately unlock the file. When rpc.lockd receives an unlock request with svid that does not match the recorded svid of the corresponding lock, it returns an "unlock granted" to the client but does not actually pass the unlock operation to the kernel. Presumably this is for purposes of crash recovery, in which the lock state may have been lost by the rpc.lockd server and the client process really did own the lock. The result of this is that locks may be "leaked" by the server, e.g.: >How-To-Repeat: On the NFS client: haessal# daemon -p pid sleep 100000 <-- the daemon process creates and locks pid haessal# kill -KILL `cat pid` <-- the unlock request is generated by the child pid haessal# lockf -t 0 -k pid echo Yay <-- the server ignored it since it doesn't know the child inherited the lock lockf: pid: already locked On the NFS server: dosirak# lockf -t 0 -k pid echo Yay lockf: pid: already locked >Fix: Probably difficult. >Release-Note: >Audit-Trail: >Unformatted: