I'm quite aware of all this. What I was asking for were those "security issues"
that you claim to be solved>by randomizing the inode-to-filehandle-relationship on every
server reboot.
I have not really wanted to spell it out.
The following is mainly about NFSv2/v3.
Client requests a File Handle for a export file system from mountd, mountd
checks its access list, and if the client has access returns a File Handle (for
an exported file system). This File Handle can then be used to get directory
listing from the top of the export file system.
NFSD gets a File Handle and UID GID information and returns information or data
e.g. read a file, get a directory listing based on the File Handle.
Security Issue
File Handles were/are fixed. e.g. something like Major/Minor device number of
the disk the file-system was on and inode ie a sort of formula, which has a
stable file handle for every file/directory/etc.
The problem (I hope it is still not) is that once you have the file handle for
a file or directory you can access any file on a system, exported or not.
Because of the formula way of creating file handles makes it possible to guess
the file handle for say /, which could be accessed even if it was not exported.
Why, because NFSD (and the protocol) assume everyone is nice, and that if you
have a file handle then mountd must have given it to you, and hence NFSD just
accepts it, so you could read /etc/password, even if /etc was not exported.
NFSD did not re-check access lists for the same things as mountd, if it did check access lists it
would slow NFSD down, so some mountd/nfsd implementations made a portion of the file handle random
at the time of export, this fixes the security issue of "skipping mountd" or being able
to easily "guess" file-handles.
Now (I hope)
CPU performance has increased, and some NFSD talk to mountd to get a list of IP
address which are able to present File Handles. i.e. NFDS does some basic IP
address checking, in the past it did not check anything that mountd did. These
implementations which check the IP for example, may have gone back to a stable
file handle between reboots.
I can not give you a list Unix flavours which do random file handles at export (if they
did, or if they still do), all I can say is that it's a possible cause of "Stale
File Handle" after a reboot, when it is not expected to happen.
OpenSolaris ZFS nfs share presents the same NFS file-handle but NFSD checks
with mountd about the client IP address.
Some light reading
http://utcc.utoronto.ca/~cks/space/blog/unix/NFSServerSecurity
http://utcc.utoronto.ca/~cks/space/blog/solaris/SolarisMountdInnards
http://fixunix.com/sgi/110779-stale-nfs-file-handle.html # second post
This is a lot more detail
http://www.antibozo.net/ogata/webtools/nfs/README.txt
http://www.fsl.cs.sunysb.edu/docs/nfscrack-tr/index.html
If you would like to check the file handle for an export file system
before and after a reboot you can use the following tool
"nfs is an NFS protocol client package that allows you to test security
of NFS implementations. It includes a mountd client that enumerates
exported filesystems and their root filehandles, and an NFS client that
allows you to perform file transfers, directory listings, object
renaming, and most other procedures supported by NFS. The NFS client
resembles an FTP client, and includes command line completion and a
history mechanism. It supports versions 2 and 3 of the NFS protocol, and
can use TCP or UDP transport. Both programs compile successfully on
Linux, FreeBSD, IRIX, and Solaris."
http://www.antibozo.net/ogata/webtools/index.html
e.g. the file handle for /export/home
./mtq localhost
Connected to mountd server at udp localhost:45743.
/export/home:
fe9566320838bf750a00030000000000b70100000a00030000000000b7010000
Cheers
