UNIX System Administration Handbook - Evi Nemeth [293]
Unfortunately, this scheme requires the directory /anchor to exist in the root directory of all client machines. If a client gets filesystems from several other hosts, the root can get cluttered. Consider providing a deeper hierarchy (e.g., /home/anchor, /home/rastadon, etc.). We recommend implementing such a scheme with one of the automounter daemons described starting on page 504.
Security and NFS
NFS provides a convenient way to access files on a network, and thus it has great potential to cause security problems. In many ways, NFS is a poster child for everything that is or ever has been wrong with UNIX security.
The NFS protocol was originally designed with essentially no concern for security. Later, the underlying RPC protocol was revised to allow the use of pluggable authentication modules. However, the new specification stopped short of actually specifying or recommending any particular security mechanism.
Several contenders stepped up to the plate: Sun, which hoarked out an enormous public-key-based hairball that other vendors generally ignored, and Kerberos, which extended its standard authentication to RPC. Both of these schemes help to ensure that remote users really are who they say they are. However, neither actually encrypts data on the network, so you’re still at the mercy of anyone running a packet sniffer.
See page 670 for more information about Kerberos.
If your site is already using Sun’s public key system or Kerberos, by all means use it for NFS. You bought the cow; you might as well drink the milk. If not, the NFS situation doesn’t provide much impetus for installing such a system. Although a paranoid site might find both systems worth investigating, in reality both systems offer only a minimal increase in security over good common sense. For the average site, tight control over shared filesystems is adequate protection from unwanted access.
The greatest risk is presented by on-site machines that are legally allowed to mount a filesystem. If anyone that you don’t fully trust has root access on a client host, don’t export any filesystems to that host.
If your site has installed a network firewall, it’s a good idea to block access to TCP and UDP ports 2049, which are used by NFS.2
You should also block access to the SunRPC portmap daemon, which normally listens on TCP and UDP ports 111. It’s implicit in these precautions but perhaps worth saying explicitly that NFS filesystems should not be exported to nonlocal machines (WebNFS excepted).
See page 675 for more information about firewalls.
17.2 SERVER-SIDE NFS
A server is usually said to “export” a directory when it makes the directory available for use by other machines. Solaris uses the word “share” instead. For clarity, we’ll use “export” throughout this chapter.
The process used by clients to mount a filesystem (that is, to learn its secret cookie) is completely separate from the process used to access files. The operations use separate protocols, and the requests are served by different daemons: mountd for mount requests and nfsd for actual file service. On some systems, these daemons are called rpc.nfsd and rpc.mountd as a reminder that they rely on SunRPC as an underlying protocol (and hence require portmap to be running; see page 826).
On an NFS server, both mountd and nfsd should start when the system boots, and both should remain running as long as the system is up. Most systems start them for you automatically; the system startup scripts check to see if you have any exports configured and run the daemons if you do.
mountd and nfsd share a single access control database that tells which filesystems should be exported and which