UNIX System Administration Handbook - Evi Nemeth [292]
Disk quotas
Access to remote disk quota information can be provided by a similar out-of-band server, rquotad. An NFS server will enforce disk quotas, but users cannot view their quota information unless rquotad is running on the remote server. We consider disk quotas to be largely obsolete, so we won’t discuss rquotad any further.
Global UIDs and GIDs
UNIX identifies users and groups by number. If machine X shares files with machine Y, then UID 644 had better refer to the same user on both systems or a serious security or privacy problem could result.
See Chapter 6 for more information about UIDs and GIDs.
Some NFS servers have been hacked to provide a way to map remote UIDs and GIDs to local ones, but this feature is not part of the NFS protocol and it can’t be relied upon to work among multiple OSes. We recommend that you manage UIDs the old-fashioned way: by making sure that they always map to the same users on all machines that share files. To forestall administrative headaches, it’s best if UIDs and GIDs are unique across your entire site.
NFS servers need not allow remote users to log in. In fact, remote users do not even need to have entries in the /etc/passwd file unless the server uses an unusual option such as Red Hat’s map_nis facility.
Root access and the nobody account
While users should generally be given identical privileges wherever they go, it’s traditional to prevent root from running rampant on NFS-mounted filesystems. By default, NFS servers intercept incoming requests made on behalf of UID 0 and change them to look as if they came from some other user. The root account is therefore not entirely shut out, but it is limited to the abilities of a normal user.
On most systems, a placeholder account named “nobody” is defined specifically to be the “user” that a remote root masquerades as on an NFS server. Its UID varies and is not important; it is often -2 or -2’s two’s-complement equivalent, 65,534. The important thing is that the UID not be shared with any real user. On Solaris and HP-UX, access will be denied altogether if root is mapped to UID -1.
The intent behind these precautions is good, but their ultimate value is not as great as it might seem. Root on an NFS client can su to whatever UID it wants, so user files are never really protected. System logins such as “bin” and “sys” aren’t UID-mapped,1
so any files they own (a large percentage of the system files) are vulnerable to attack. The only real effect of UID mapping is to prevent access to files that are owned by root and not readable or writable by the world.
Cookies and stateless mounting
A client must explicitly mount an NFS filesystem before using it, just as it must mount a filesystem stored on a local disk. However, because NFS is stateless, the server does not keep track of which clients have mounted each filesystem. Instead, the server simply discloses a secret “cookie” at the conclusion of a successful mount negotiation. The cookie identifies the mounted directory to the NFS server and so provides a way for the client to access its contents.
Unmounting and remounting a filesystem on the server normally changes its cookie. As a special case, cookies persist across a reboot so a server that crashes can return to its previous state. But don’t try to boot single-user, play with filesystems, then boot again; this procedure will revoke cookies and make clients unable to access the file systems they have mounted until they either reboot or remount.
Once a client has a magic cookie, it uses the RPC protocol to make requests for filesystem operations such as creating a file or reading a data block. Because NFS is stateless, the server doesn’t care what requests the client has or hasn’t made before. In particular, the client is responsible for making sure that the server acknowledges write requests before it deletes its own copy of the data to be written.
Naming conventions for shared filesystems
It