bkc@sun.soe.clarkson.edu (Brad Clements) (11/03/88)
Hi We have a MicroVax II running the dec 28, 1988 release of Mt. Xinu 4.3 BSD unix. Over the past three months I created several new root level directories. These directories are readable/executable by user,group and world. Any normal user can cd to these directories, look at files and cd to lower level directories. However the PWD command fails with getwd: couldn't open .. once in or below these directories. yet all directories (. and ..) in each of these directories are readable and executable by all. Super user does not get this error. I've looked at the i-node numbers, my untrained eye doesn't detect anything peculiar. fsck runs w/ no errors. Not all of the root level directories I've made have these problems. But all those that do have these problems are at the root level, and are the root directories of other partitions. Find's weekly updatedb returns either 'bad status' (from lstat) or 'bad directory' on these directories. It also returns bad status on one root level file (genvmunix) which is readable and executable by all! An ls -d on /. and /.. both return r-x for group and world. Does anyone out there have any idea what's wrong with these directories? Its irritating, but so far there doesn't appear to be anything else wrong w/ the system. Thanks for any ideas! Brad Clements Clarkson University
tar@ksuvax1.cis.ksu.edu (Tim Ramsey) (11/04/88)
My guess is that the mount point has the wrong permissions. Unmount the
file system and check the permissions on the mount directory. You will
probably want to make it 0755.
I had this problem on an ATT 3B15 running SysV 2.1.2. The mount point had
permission 000 (I don't know how it got set to that -- I didn't do it!).
When I was root everything was happy. When I wasn't root things like pwd
and ls -d . (where . was the root of the filesystem) failed.
I just checked this on a VAX 11/780 running 4.3BSD. The problem is there,
too.
It seems odd that the permissions of the mount point affect access to the
mounted file system. Is this a bug or feature?
--
Timothy Ramsey, USENET Keeper-Upper | Ada:
BITNET: tar@KSUVAX1 | Just say NO!
Internet: tar@ksuvax1.cis.ksu.edu |
UUCP: ... !{pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!tarlvc@cbnews.ATT.COM (Lawrence V. Cipriani) (11/05/88)
In article <1165@ksuvax1.cis.ksu.edu> tar@ksuvax1.cis.ksu.edu (Tim Ramsey) writes: >It seems odd that the permissions of the mount point affect access to the >mounted file system. Is this a bug or feature? This is a feature. The permissions of the mount point determine the permission of the directory after the mount. The permission on the raw disk only control access to that disk device as if it was a file. -- Larry Cipriani, AT&T Network Systems, Columbus OH, Path: att!cbnews!lvc Domain: lvc@cbnews.ATT.COM
guy@auspex.UUCP (Guy Harris) (11/06/88)
>>It seems odd that the permissions of the mount point affect access to the >>mounted file system. Is this a bug or feature? >This is a feature. The permissions of the mount point determine the permission >of the directory after the mount. The permission on the raw disk only control >access to that disk device as if it was a file. The permission on the raw disk doesn't enter into it. The most straightforward model of file system behavior would say that the permissions *on the root directory of the mounted file system* should be the only ones that control whether you should be able to find ".." or not. In fact, at least under SunOS 4.0 (and probably under other systems), the permissions on the mount point only affect *certain* accesses. If I have a mount point of mode 0, and I mount another file system atop it whose root directory has permissions "rwxrwxrwx", I have no problems creating or removing directories in that root directory, regardless of whether I'm "root" or not. I just can't get at ".." This appears to be because the code that special-cases ".." (this special case has been there since V7, in order that references to ".." in the root directory of a mounted file system work the same as references to ".." elsewhere), when it notices that it will be searching for "..", checks whether the directory being searched is the root of a mounted file system; if so, it finds the mounted-on vnode, and searches that for ".." instead. This means that it checks the permissions of that directory, instead of the permissions of the root directory of the mounted file system. (I am surprised, however, at the claim that VAX 4.3BSD exhibits this behavior; the 4.3BSD "namei" appears to specifically *avoid* permissions checks before searching a mount-point directory (that's what the label "dirloop2" is for - you go to "dirloop" to check permisions before continuing the search, and "dirloop2" to bypass the permissions check). Perhaps the 4.3BSD system really was, say, 4.3BSD+NFS, complete with the vnode changes, so it exhibits the same symptoms as SunOS?) There are ways of fixing this problem in a vnode kernel if the mounted-on file system is a local file system; you can tell that file system to bypass permission checks if the vnode you're searching is a ".." vnode. The VOP_LOOKUP operation has a "flags" parameter, and a LOOKUP_PARENT flag could be added. This would work for local file systems; if LOOKUP_PARENT were specified, the code would just bypass the "do I have search permission" check. However, this won't necessarily work for, say, a remote file system, because you have to convince the *server* that you really should be allowed to search that directory because really, officer, I'm just looking for "..", honest, trust me.... The server is quite likely not to be amused by such a request. The current NFS protocol has no way of saying "just give me '..'". The last draft of the proposed NFS version 3 protocol has this option; the "lookup" call has a "give me the parent of this directory" flag (stuck in so that you don't hardcode the UNIX notion that ".." means "parent directory" into the protocol), so it might be possible to use this with NFS3. I don't know whether AT&T's RFS has a "give me the parent directory" request, but if it does, a vnode implementation of RFS would use it when the LOOKUP_PARENT was passed.
tar@ksuvax1.cis.ksu.edu (Tim Ramsey) (11/06/88)
In article <1165@ksuvax1.cis.ksu.edu> I write: >It seems odd that the permissions of the mount point affect access to the >mounted file system. Is this a bug or feature? In article <1971@cbnews.ATT.COM> lvc@cbnews.ATT.COM (Lawrence V. Cipriani) writes: >This is a feature. The permissions of the mount point determine the permission >of the directory after the mount. The permission on the raw disk only control >access to that disk device as if it was a file. I think you are referring to the special file in /dev. I was commenting on the mount point and the filesystem root directory. To add to the confusion (this is 4.3BSD): % ls -ld /mnt drwxr-xr-x 7 root 512 Aug 7 23:47 /mnt % umount /mnt % ls -ld /mnt drwxr-xr-x 2 root 512 Jan 88 09:12 /mnt % chmod 000 /mnt % ls -ld /mnt d--------- 2 root 512 Jan 88 09:12 /mnt % mount /mnt % ls -ld /mnt drwxr-xr-x 2 root 512 Jan 88 09:12 /mnt The root directory of the mounted filesystem "hides" the mount directory. So you don't see the 000 permissions. I spent a goodly amount of time looking for the problem the first time I ran into this. It appears that access checks are done for both the mount directory and the file system root directory. You have to pass both to read/write/execute. I dunno, but this seems like a bug. -- Timothy Ramsey, USENET Keeper-Upper | Ada: BITNET: tar@KSUVAX1 | Just say NO! Internet: tar@ksuvax1.cis.ksu.edu | UUCP: ... !{pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!tar