Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: PWD gives getwd: couldn't open .. on world r-x root directories
Message-ID: <408@auspex.UUCP>
Date: 6 Nov 88 01:41:10 GMT
References: <1590@sun.soe.clarkson.edu> <1165@ksuvax1.cis.ksu.edu> <1971@cbnews.ATT.COM>
Reply-To: guy@auspex.UUCP (Guy Harris)
Distribution: na
Organization: Auspex Systems, Santa Clara
Lines: 60

>>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.