لطفا منتظر باشید ...
Username Mapping Options
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 filesone 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.NOTE
align=left border=0> This discussion assumes that users have accounts on both the
client and the server. If the server is used only
as a file server, it might lack user accounts. This may be a reasonable
configuration for read-only servers, and even for some read/write
configurations. If a read/write server has several clients, though, synchronization
of UIDs among the clients is important, even if the server doesn't have
accounts for all the users. It's often simplest to configure an NFS server
that holds user files with user accounts, even if those users can't log onto
the NFS server directly. If the server doesn't hold files that are owned by
users, username mapping is probably unimportant.
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
WARNING
align=left border=0> Don't try to change a UID or GID when the user or members of
the group are logged on. Doing so is likely to result in an inability to save
work or read files, and running programs may misbehave in program-specific
ways when this happens. If you make such a change accidentally, you might try
undoing it, or advise the user to log out and then back in. If the user needs
to save any files, they can be saved in a common area, such as /tmp .
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
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
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
User
User ID on gingko
User ID on larch
alyson
500
504
james
501
501
jennie
502
503
samuel
503
502
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
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: /home larch(rw,map_static=/etc/nfs/larch-map)
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
resemble
beginning with pound signs ( # ) are comments and are ignored;
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,
the client's UID 504 to the server's UID 500. If the server column consists of
a single dash ( - ), the NFS server squashes accessconverting 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.
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.
squashes all GIDs below 100, and maps client GIDs of 100102 onto a local GID
of 100. Although you can map a range of client IDs onto a single server ID,
doing the reverse is meaninglessthe 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 .
