From owner-freebsd-current Thu Mar 21 13:42:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA14075 for current-outgoing; Thu, 21 Mar 1996 13:42:38 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA14000 for ; Thu, 21 Mar 1996 13:42:31 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id QAA13188; Thu, 21 Mar 1996 16:42:20 -0500 From: Bill Paul Message-Id: <199603212142.QAA13188@skynet.ctr.columbia.edu> Subject: flock() and chroot() To: current@freebsd.org Date: Thu, 21 Mar 1996 16:42:19 -0500 (EST) Cc: wpaul@skynet.ctr.columbia.edu (Bill Paul) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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. =============================================================================