Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Mar 1996 16:42:19 -0500 (EST)
From:      Bill Paul <wpaul@skynet.ctr.columbia.edu>
To:        current@freebsd.org
Cc:        wpaul@skynet.ctr.columbia.edu (Bill Paul)
Subject:   flock() and chroot()
Message-ID:  <199603212142.QAA13188@skynet.ctr.columbia.edu>

next in thread | raw e-mail | index | archive | help

I've got a question concerning file locking:

I got a bug report recently from a guy trying to use NIS inside a
chroot()ed environment. Apparently he's created a filesystem tree
which has the real /var and /dev mounted in it (I'm not sure how he
did this since he neglected to provide details -- I've asked him
to elaborate) and has set up a guest user that is placed in this
confined environment at login.

In this environment, _yp_dobind() fails, which breaks NIS client
facilities. The point where is breaks is:

        if ((lfd = open(YPBINDLOCK, O_RDONLY)) == -1)
                return(YPERR_YPBIND);
        errno = 0;
        switch (flock(lfd, LOCK_EX|LOCK_NB) == -1 && errno == EWOULDBLOCK) {
        case 0:
                close(lfd);
                return (YPERR_YPBIND);
                break;
        case 1:
        default:
                close(lfd);
                break;
        }

What's happening here is that _yp_dobind() is trying to establish
an exclusive lock on /var/run/ypbind.lock. This file should already
be exclusively locked by ypbind, so the attempt should fail with
EWOULDBLOCK. If this happens, _yp_dobind() then knows that ypbind
is actually running and falls through to the rest of the routine,
otherwise it bails.

In this case, the flock() is actually succeeding even though ypbind is
running. I think this is because ypbind has flock()ed /var/run/ypbind.lock
whereas _yp_dobind() is trying to flock() $CHROOT/var/run/ypbind.lock.
The question is: is this the correct behavior? On the one hand, since
$CHROOT/var/run/ypbind.lock is located under a different mount point,
it seems reasonable to assume that the kernel is refering to it using
a different filesystem object than /var/run/ypbind.lock. On the other
hand, they are both the same file. On the third hand, chroot() confuses
the whole matter even further.

I can fix this particular problem by looking for ypbind in a different
way (you can verify that an RPC server is running by poking at its
NULLPROC procedure and seeing if it responds), but I'd still like to
know if the observed flock() behavior is bogus or not.

Note that all this is happening with FreeBSD-current:

FreeBSD 2.2-960212-CURRENT #0: Fri Mar 15 14:52:11 CST 1996

-Bill

-- 
=============================================================================
-Bill Paul            (212) 854-6020 | System Manager
Work:         wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home:  wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
=============================================================================
License error: The license for this .sig file has expired. You must obtain
a new license key before any more witty phrases will appear in this space.
=============================================================================



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603212142.QAA13188>