Managing NFS and NIS, 2nd Edition - Mike Eisler [146]
You can prevent damage to files by restricting write permissions and enforcing user authentication. With NFS you have the choice of deploying some simple security mechanisms and more complex, but stronger RPC security mechanisms. The latter will ensure that user authentication is made secure as well, and will be described later in this section. This section presents ways of restricting access based on the user credentials presented in NFS requests, and then looks at validating the credentials themselves using stronger RPC security.
RPC security
Under the default RPC security mechanism, AUTH_SYS, every NFS request, including mount requests, contains a set of user credentials with a UID and a list of group IDs (GIDs) to which the UID belongs. NFS credentials are the same as those used for accessing local files, that is, if you belong to five groups, your NFS credentials contain your UID and five GIDs. On the NFS server, these credentials are used to perform the permission checks that are part of Unix file accesses — verifying write permission to remove a file, or execute permission to search directories. There are three areas in which NFS credentials may not match the user's local credential structure: the user is the superuser, the user is in too many groups, or no credentials were supplied (an "anonymous" request). Mapping of root and anonymous users is covered in the next section.
Problems with too many groups depend upon the implementation of NFS used by the client and the server, and may be an issue only if they are different (including different revisions of the same operating system). Every NFS implementation has a limit on the number of groups that can be passed in a credentials structure for an NFS RPC. This number usually agrees with the maximum number of groups to which a user may belong, but it may be smaller. On Solaris 8 the default and maximum number of groups is 16 and 32, respectively. However, under the AUTH_SYS RPC security mechanism, the maximum is 16. If the client's group limit is larger than the server's, and a user is in more groups than the server allows, then the server's attempt to parse and verify the credential structure will fail, yielding error messages like:
RPC: Authentication error
Authentication errors may occur when trying to mount a filesystem, in which case the superuser is in too many groups. Errors may also occur when a particular user tries to access files on the NFS server; these errors result from any NFS RPC operation. Pay particular attention to the group file in a heterogeneous environment, where the NIS-managed group map may be appended to a local file with several entries for common users like root and bin. The only solution is to restrict the number of groups to the smallest value allowed by all systems that are running NFS.
Superuser mapping
The superuser is not given normal file access permissions to NFS-mounted files. The motivation behind this restriction is that root access should be granted on a per-machine basis. A user who is capable of becoming root on one machine should not necessarily have permission to modify files on a file server. Similarly, a setuid program that assumes root privileges may not function properly or as expected if it is allowed to operate on remote files.
To enforce restrictions on superuser access, the root's UID is mapped to the anonymous user nobody in the NFS RPC credential structure. The superuser frequently has fewer permissions than a nonprivileged user for NFS-mounted filesystems, since nobody 's group usually includes no other users. In the password file, nobody has a UID of 60001, and the group nobody also has a GID of 60001. When an executable, that is owned by root with the setuid bit set on the permissions, runs, its effective user ID is root, which gets mapped to nobody. The executable still has permissions on the local system, but it cannot get to remote files unless they have been explicitly exported with