2009-07-13
Some stuff on NFS access restrictions
Roughly speaking, there's two sorts of access restrictions that an NFS server can put on a client: what filesystems the client can access, and what directories in the filesystems the client can access (this is necessary when you export a subdirectory in the filesystem, instead of the whole filesystem).
(This ignores just firewalling off the client entirely. The NFS server code generally doesn't have any special handling for this, because from its perspective, not allowing someone to talk at all is functionally identical to not allowing them access to any filesystems.)
Per-filesystem access restrictions are generally very solid, because it is easy for the NFS server to tell what filesystem a client is trying to access; the information is generally directly present in the NFS filehandle and cannot be usefully altered by the client. The same is not true of directory restrictions, because most NFS servers do not have any good way of knowing if an inode (and thus an NFS filehandle) falls under a directory hierarchy, so the only way they have of enforcing this limit is by never letting you have a filehandle for something outside your allowed directory hierarchy.
This has two problems: first, we've already seen how well filehandle secrecy works in practice, and second, there have traditionally been any number of creative ways to trick an NFS server into letting you escape from your 'jail' and get a filehandle for somewhere else in the filesystem. Hence the traditional advice that you should always export whole filesystems, or at least not count on subdirectory restrictions for much security.
That the NFS server doesn't really know what directory hierarchy a filehandle falls under is also why you generally can't export two separate bits of the same filesystem to the same client with different options (one read-write, one read-only, for example). If the server allowed you to specify different options, it would have no way of figuring out which set to apply to a given filehandle.
Shell scripts should not use absolute paths for programs
There is a certain habit in shell scripts of referring to uncommon
programs by their absolute path; for example, if you need to run lsof,
people will write '/usr/sbin/lsof ....' in their shell script. We
do a certain amount of that here, and then recently one of our shell
scripts started reporting:
netwatch: line 15: /usr/sbin/lsof: No such file or directory
You see, you shouldn't do this, because every so often Unix vendors change where they put commands (or, in multi-vendor environments, two vendors disagree about it). If you used hard-coded paths, your script just broke.
(In this case, Ubuntu 6.06 put lsof in /usr/sbin and Ubuntu 8.04
moved it to /usr/bin, probably on the sensible grounds that it's
useful for ordinary users too.)
The right way to do this is to add the directory you expect the command
to be in to your script's $PATH and then just invoke the command
without the absolute path. If the command gets moved, well, hopefully it
will be to somewhere else on $PATH (as it was in this case), and your
script will happily keep working. Better yet, this way your script can
work transparently across different Unix environments without having to
be changed or conditionalized; just add all of the possible directories
to your script's $PATH and be done with it.
(This does point out that the Bourne shell could do with a simple way of
adding something to your $PATH if it isn't already there.)