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:


        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.


freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to