Some notes on UID and GID remapping in the Illumos/OmniOS NFS server
As part of looking into this whole issue,
I recently wound up reading the current manpages for the OmniOS NFS
server and thus discovered that it can remap UIDs and GIDs for
clients via the uidmap=
and gidmap=
NFS share options. Server
side NFS ID remapping is not as neat or scalable as client side
remapping, but it does solve my particular problem, so I've now played around with it
a bit and have some notes.
The feature itself is an Illumos one and is about two years old now, so it's probably been integrated into most Illumos-based releases that you want to use (even though we mostly don't update, you really do want to do so every so often). It's certainly in OmniOS r151014, which is what we use on our fileservers.
The share_nfs manpage describes mappings as
[clnt]:[srv]:access_list
. Despite its name, the access_list
bit is just for matching the client; it doesn't create or change
any NFS mount access permissions, which are still set through rw=
and so on. You can also use a different mechanism in each place for
identifying clients, say a netgroup for filesystem access and then
a hostname to identify the client for remapping (which might be
handy if using a netgroup has side effects).
The manpage also describes uidmap
(and gidmap
) as 'remapping
the user ID (uid) in the incoming request to some other uid'. This
is a completely accurate description in that the server does not
remap IDs in replies, such as in the results from stat()
system
calls. For example, if you remap your client UID to your server
UID, 'ls -l
' will show that your files are owned by the server-side
UID, not you on the client. This is potentially confusing in general
and will probably cause anything that does client-side UID or GID
checking to incorrectly reject you.
(This design decision is probably due to the fact that the UID and GID mapping is not necessarily 1:1, either on the server or for that matter on the client. And yes, I can imagine merely somewhat perverse client side uses of mapping a second local UID to a server UID that also exists on the client.)
Note that in general UID remapping is probably more important than GID remapping, since you can always force a purely server side group list (as far as I know this NFS server lookup entirely overwrites the group list from the client).
PS: I don't know how well this scales on any level. Since all of the mappings have to be specified as share options, I expect that this won't really be very pleasant to deal with if you're trying to do a lot of remapping (either many IDs for some clients or many clients with a few ID remappings).
|
|