On Oct 18, 2005, at 8:12 PM, der Mouse wrote:

> For access checks, I don't think the pathname is a right answer  
> either.
> What do you need a pathname for?  If it's a call involving a pathname
> walk (such as open()), you have a pathname at hand; if not, you  
> have to
> either have it saved or base your checks on the vnode itself, and in
> the latter case a path to it is misleading because it introduces a
> bunch of unrelated directories.  I think it would be better to have
> something like the fh*() family of syscalls for this purpose - or
> perhaps a vnode filesystem, in which live vnodes appear as entries  
> in a
> directory, since all you use the pathname for is as a handle on the
> vnode.

Opening directly by file handle using fhopen(2) has problems.

Notably: In Unix, restricting the permissions of a common parent in  
the directory hierarchy effectively restricts the permissions  
underneath that common parent, because people can't traverse the  
common parent to get to the children.

This is why fhopen(2) is restricted to super-user.  To "fix" the  
issue, you would have to traverse back up the tree and check the  
access control on each parent.

Of course, since files can be "enclosed" by more than one directory,  
to do this you need the file + an enclosing directory.  Once you have  
the enclosing directory, it's easy to traverse back, since  
directories can have only one parent ("..").

-- thorpej