From owner-freebsd-fs Wed May 17 10:27: 7 2000 Delivered-To: freebsd-fs@freebsd.org Received: from akat.civ.cvut.cz (akat.civ.cvut.cz [147.32.235.105]) by hub.freebsd.org (Postfix) with ESMTP id 209CB37B5A2 for ; Wed, 17 May 2000 10:27:00 -0700 (PDT) (envelope-from pechy@hp735.cvut.cz) Received: from localhost (pechy@localhost) by akat.civ.cvut.cz (8.10.0/8.10.0) with ESMTP id e4HHPdK03538 for ; Wed, 17 May 2000 19:25:39 +0200 (CEST) X-Authentication-Warning: akat.civ.cvut.cz: pechy owned process doing -bs Date: Wed, 17 May 2000 19:25:38 +0200 From: Jan Pechanec X-Sender: pechy@akat.civ.cvut.cz To: FreeBSD FS Mailing List Subject: ACL paper (and unix) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hi all, please, don't you have on-line version of: Gary Fernandez and Larry Allen: Extending the UNIX Protection Model with Access Control Lists I have just spent more than an hour looking for it, but no success. or, don't you know about other papers discussing ACL in unix? thank you, jan. -- Jan PECHANEC , http://pechy.civ.cvut.cz Supercomputing Center CTU, Zikova 4, Praha 6, 166 35, Czech Republic http://www.civ.cvut.cz, direct: +420 2 2435 2969, fax: +420 2 2431 0271 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri May 19 13:20:44 2000 Delivered-To: freebsd-fs@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id A4E9637B5FA; Fri, 19 May 2000 13:20:36 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (sol.cs.binghamton.edu [128.226.123.100]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with ESMTP id QAA15659; Fri, 19 May 2000 16:20:35 -0400 (EDT) Date: Fri, 19 May 2000 16:19:43 -0400 (EDT) From: Zhihui Zhang To: freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Subject: A possible bug in directory lookup code? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think I may have found a bug in the directory lookup code in FreeBSD 4.0-Release, although it does not affect normal user. Please be patient and read on. The test code I am using and its result as follows: # cat test.c #include #include main() { int error; error = rename("dir1", "dir2/."); printf("error = %d, errno = %d\n", error, errno); } # mkdir dir1 # mkdir dir2 # cc test.c # ./a.out error = -1, errno = 66 The error code returned is 66 - ENOTEMPTY not the expected 22 - EINVAL. Why do I expect EINVAL error? This is because the following code: (1) In ufs_lookup(), we have the following code for the RENAME case: if (dp->i_number == dp->i_ino) return (EISDIR); This code is never executed when you are looking for dot. (2) In rename() system call, we have the following bogus code: if ((error = namei(&tond)) != 0) { /* Translate error code for rename("dir1", "dir2/."). */ if (error == EISDIR && fvp->v_type == VDIR) error = EINVAL; <-- should change to 22 here! NDFREE(&fromnd, NDF_ONLY_PNBUF); vrele(fromnd.ni_dvp); vrele(fvp); goto out1; } See the bogus comment "Translate error ...", that is exactly what I am using in my test.c code. How does this happen (return 66 instead of 22)? I use remote debugging to find out. In vfs_cache_lookup() (invoked by VOP_LOOKUP()), it calls cache_lookup(), which returns -1 as a dot hit. Then because of the following code: if (pdp == vdp) { /* lookup on "." */ VREF(vdp); error = 0; namei() succeeds on "dir2/." lookup (error = 0). Next, when ufs_rename() is called, the tdvp and tvp are the same vnode! This will make ufs_dirempty() return 0 (even if the directory dir2/. is empty!) and ENOTEMPTY will be set to the variable error. IMHO, this is not the correct way to handle this in the kernel. But the net result from the point of the view of the user is the same (the atomic rename fails). It just makes things very confusing. ufs_dirempty() should not return 0 when the directory is empty. BTW, when I use gdb to do remote debugging, the gdb sometimes fails to display the correct line that is being executed. I wonder what's wrong. Any insights in appreciated. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message