> I'm uncertain about the need to be rootness IFF you aren't in a chroot'd
> environment. Because you still have to have access permissions to perform
> whatever operation you want. I.e. fhopen would still check that you can
> open the file for whatever access you want. And you wouldn't be able to
> write to a file you didn't open for write, etc.

Ok.. 

For one, it bypasses the the usual containing-directory-accessibility
check; I believe i've seen some unix subsystems rely on this.  (using
setuid only to chdir past a directory which is mode 700, then pop back
to the original uid and read & write queue files as the original user.
if someone can bypass the mode 700 directory by somehow guessing the
filehandler for the inner queueing directory, all bets are off about
the security of this subsystem.

I'm also concerned about the ability to do filehandle-guessing
attacks, particularly in the presence of readable but not searchable
directories.

In particular, if you put a file which is mode 0666 in a directory
which is mode 0744 (listable, but not lookupable), an attacker can
probably read enough out of the directory to be able to make a good
guess at what the filehandle is.  Maybe they need to guess the inode
generation number, but who really runs fsirand on all partitions?
Also, see the SECURITY CONSIDERATIONS section of our fsirand man
page.. (fsirand really should be integrated into newfs or run by
newfs..).

If fhopen is a local call, an attacker can probably scan generation
numbers a lot faster than they could over NFS..

					- Bill