On an isolated Linux computer, the /etc/passwd file controls the mapping of usernames to UIDs, and /etc/ group does a similar job for groups. With NFS, there are usually at least two independent /etc/passwd files ”one for the server and one for each client. Thus, a situation in which a user has one UID on the server and another UID on the client is possible, and perhaps even likely, unless care is taken in setting up accounts. There are several possible ways to work around or avoid this potential problem.
Synchronizing Client and Server User IDs
The solution that is conceptually simplest is to synchronize the UIDs and GIDs on the client and server. For instance, if a particular user has a UID of 504 on the server, you should ensure that this user has a UID of 504 on the client as well. GID assignments should be synchronized in a similar way. Unfortunately, manually adjusting UIDs in this way is tedious . This may be a viable option on a very small network with few client computers and few users, though. If you need to adjust existing UIDs, you can use the usermod command to alter a user's UID. For instance, to change abrown 's UID from 507 to 504, you'd issue the following command:
# usermod -u 504 abrown
This command will change the entries in /etc/passwd and change the UID associated with files in the user's home directory, so the user won't notice a change after logging back in. (If the user has stored files outside of the home directory, you need to manually change the ownership of those files.) This command can take some time to complete. If you interrupt it, you may need to change the ownership of some files and directories (including the user's home directory) manually.
The groupmod command serves a similar function for altering group information, but you pass the new group ID using the -g parameter. For instance, to change a GID number for the group project3 to 127, you'd issue the following command:
# groupmod -g 127 project3
One point to note about this approach is that the usernames used on the client and server don't need to match. For instance, a single user might have a username of abrown on the server but alyson on the client. When this person uses the client to access files on the server, they will appear to be owned by alyson ; but if the user logs into the NFS server, the files will appear to be owned by abrown . This feature could be confusing, but it might also be useful in some situations.
A variant on the idea of keeping UIDs and GIDs synchronized is to use an outside server to authenticate users on both the client and server. This practice will give users the same UIDs, and groups the same GIDs, on both the NFS client and the NFS server. You can use Kerberos, described in Chapter 6, for this function. Linux's NFS implementation includes explicit support for NIS authentication, via the map_nis option. When you include this option in a definition for a specific client in /etc/exports , the NFS server defers to the NIS server in creating a username mapping for that client and export.
Using a Server-Side User ID Map
Suppose you're administering a two-computer network with four users whose usernames and UIDs are outlined in Table 8.1. In this example, gingko is the server and larch is the client. Of these four users, only one ( james ) has the same UID on both systems. Without special configuration, james would be able to access his own files correctly. From larch , though, alyson would find that her files stored on gingko would be owned by an unidentified user (UID 500, which has no counterpart on larch ). The final two users, jennie and samuel , would seem to own each others' files.
Table 8.1. Hypothetical User and Group IDs on Two Computers
One way to work around the mapping problem is to have the NFS server maintain a file that includes mapping information akin to that in Table 8.1. You tell the server to use such a file with the map_static option, and you pass the name of the mapping file along with this option. For instance, an entry in /etc/exports might look like this:
This tells the system to export /home to larch , and to use the file /etc/nfs/larch-map for the mapping file. Because the map_static option is part of the option list for a client, it's possible to create separate mapping lists for different clients. The contents of larch-map , matched to Table 8.1, might resemble Listing 8.2. Lines beginning with pound signs ( # ) are comments and are ignored; Listing 8.2 includes a couple of comment lines to document the file and remind you of the meaning of each column of information. Each noncomment line begins with uid or gid to identify the mapping of UIDs or GIDs, respectively. The next item is the ID number or numbers ( expressed as a range, as in the first entry's 0-99 ) on the client system. The final entry is the local UID or GID to which the remote ID is mapped. Thus, for instance, Listing 8.2 maps the client's UID 504 to the server's UID 500. If the server column consists of a single dash ( - ), the NFS server squashes access ”converting it to that of the anonymous user, as discussed earlier.
Listing 8.2 Sample Contents of a UID Mapping File
# Mapping for client larch # remote local uid 0-99 - # squash uid 504 500 uid 501 501 uid 503 502 uid 502 503 gid 0-99 - # squash gid 100-102 100
It's important that every user's ID appear in the mapping file. Listing 8.2, for instance, doesn't omit UID 501, although it maps to the same number on both systems. Omitting the UID is likely to result in a spurious mapping, and therefore problems. Listing 8.2 explicitly squashes all the system UIDs (those numbered below 100). It also squashes all GIDs below 100, and maps client GIDs of 100 “102 onto a local GID of 100. Although you can map a range of client IDs onto a single server ID, doing the reverse is meaningless ”the server would have no idea which of the local IDs to use when it saw an attempt to create a file with a particular remote ID.
As with manual client and server ID synchronization, it's possible for the usernames on the client and server to be different with this approach. The mapping file works exclusively on user and group IDs; it doesn't care about usernames. To avoid confusion, it's probably best to keep usernames the same across clients and servers, whenever possible.
Using a Client-Side Mapping Daemon
Another way around the mapping problem is to use the map_daemon option in the server, which allows a special server (called ugidd or rpc.ugidd ) that runs on the client to perform username mapping. Unfortunately, this option has several problems. For one thing, the ugidd server is difficult to find. Of the distributions discussed in this book, only Debian ships with it. Another problem is that the ugidd server runs on the client, which can result in much more complex configuration, as you must install the program on all your clients. Unless you block access to ugidd (say, using /etc/ hosts .allow ), the server can be used by miscreants to discover all the usernames on your NFS clients, which is better made impossible . Finally, and in many ways most important, the server is very finicky and may not work at all, or it may map all users to nobody .