Re: nfsbug, bugs

[smb () research att com (smb () research att com)]

         > The best you can do is get a non-broken fsirand and rerun it on
         > your system.  This will randomize the numbers nfs uses for file hand
        les.
         > After doing this any system currently accessing filesystems exported
         > from your host will have to remount to get valid file handles.

         By non-broken, do you mean one that does not use the same seed for each
         randomizaton, or something complete different?

Older versions of fsirand used a very non-random seed for the random
number generation; you could guess it in a few hundred tries, as a rule.

         > How can you use the filehandle?  You could stick it in a variable
         > and pass it off to nfs to request operations be done on the file
         > associated with the handle.

         Anyone care to elaborate?

NFS operations are all based on file handles.  To look up a file name
in a directory, the client passes the server the directory's file handle
and the name of the component being searched for; the server returns the
file handle for that component.  Read and write operations use a file
handle to specify which file is to be modified.  In other words, having
a file handle is everything.

In normal operation, clients mount remote file systems by talking to
mountd.  Assuming the (inadequate) checks succeed, the file handle for
the root inode of that file system is passed back to the client; it's
used for doing directory tree walks to reach any file in that subtree.
Thus, someone who can guess the file handle of the root inode can bypass
most of the security checking.

I should note here that file handles are supposed to be opaque 32 byte
quantities to the client.  In practice, they contain things like the
device number (in the server's space, not the client's), the i-node
involved (which for the root i-node is always 2), and some random quantity.
It's the random quantity that's the trouble here -- it isn't random.