From owner-freebsd-questions@FreeBSD.ORG Thu Sep 21 22:24:19 2006 Return-Path: X-Original-To: questions@freebsd.org Delivered-To: freebsd-questions@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A333016A40F for ; Thu, 21 Sep 2006 22:24:19 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42FAC43D53 for ; Thu, 21 Sep 2006 22:24:19 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin03-en2 [10.13.10.148]) by smtpout.mac.com (Xserve/8.12.11/smtpout04/MantshX 4.0) with ESMTP id k8LMOIcH000424; Thu, 21 Sep 2006 15:24:19 -0700 (PDT) Received: from [17.214.13.96] (a17-214-13-96.apple.com [17.214.13.96]) (authenticated bits=0) by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id k8LMODN0020612; Thu, 21 Sep 2006 15:24:16 -0700 (PDT) In-Reply-To: <20060921214316.GD673@iphouse.com> References: <20060921182252.GA24321@xor.obsecurity.org> <20060921214316.GD673@iphouse.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6180D198-A44B-46D0-8A0B-FC5D3ACA115C@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Thu, 21 Sep 2006 15:24:12 -0700 To: Robert Joosten X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: questions@freebsd.org Subject: Re: 6.1 and NFS X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2006 22:24:19 -0000 On Sep 21, 2006, at 2:43 PM, Robert Joosten wrote: >> rpc.lockd remains unreliable; avoid using it if practical. > > Hmmm, is there a way to run pxe-boxes without rpc.lockd and then still > able to run adduser and so on ? Safely? No. But then, flock() doesn't work via NFS even if rpc.lockd is running, so you aren't any worse off. Details follow: adduser invokes pw underneath, and pw should share the same password locking convention that vipw uses to avoid simultaneous/conflicting updates to the password files. Both pw and vipw use the pw_lock() routine from src/lib/libutil: pw_lock(void) { if (*masterpasswd == '\0') return (-1); /* * If the master password file doesn't exist, the system is hosed. * Might as well try to build one. Set the close-on-exec bit so * that users can't get at the encrypted passwords while editing. * Open should allow flock'ing the file; see 4.4BSD. XXX */ for (;;) { struct stat st; lockfd = open(masterpasswd, O_RDONLY, 0); if (lockfd < 0 || fcntl(lockfd, F_SETFD, 1) == -1) err(1, "%s", masterpasswd); /* XXX vulnerable to race conditions */ if (flock(lockfd, LOCK_EX|LOCK_NB) == -1) { if (errno == EWOULDBLOCK) { errx(1, "the password db file is busy"); } else { err(1, "could not lock the passwd file: "); } } [ ... ] Note the "XXX"es. And, as Mark said in the section I quoted in my previous email on this thread: > flock() always returns as if it succeeded on NFS files, when in > fact it is a no-op. There is no way around this. However, I believe that some systems have actually re-implemented the BSD flock() call in terms of calling the POSIX lockf(), which would attempt to use rpc.lockd and thus have some chance of working over NFS. I believe this was done in Linux by Andy Walker and for MacOS X by Justin Walker (odd naming coincidence, there), IIRC; perhaps some of these changes have made their way back to the other BSDs. -- -Chuck