On Tue, 28 Nov 2000, Greywolf wrote:

> Okay, is there a reason that getfh() shouldn't be mortal-enabled? It
> already does path checking for accessibility; and since a stat() on a
> non-readable file is ok, fhstat shouldn't be a problem, either.
> And finally, why not make fhopen() respect the permissions on the given
> file?

Ok, out of order:

Why do you think fhopen() doesn't respect the permissions on a file? I'm
looking at fhopen() source, and there are VOP_ACCESS() calls for both
read and write. ??

> I.e. why are these calls restricted to the super-user?  They'd be great
> for providing against race conditions which might occur in the mortal
> realm...
> 
> I must be missing something.

To answer the other part:

Repeating myself: there is nothing which prevents a malicious program from
creating file handles of its own accord. They do NOT have to have come
from getfh(). So if we trusted file handles passed in from userland, then
we are permitting a process to get around all of the checks in the
directory hierarcy. Look at the archives from this list when I first
suggested the calls, and all of the security questions which came up. The
main thing is that permissions on a file are more than just permissions on
an inode, they are also permissions on enclosing directories. fhopen()
fundamentally circumvents that protection, which is why it is restricted
to the super user.

getfh() is restricted as the very same file handles are used by nfs for
its file manipulation. If we let a user make a getfh() call, they then
could attack the nfs server with spoofed packets, and get at that file.

Also see fsirand() - part of this protection with getfh is to protect the
generation numbers on the files.

Take care,

Bill