Why NFSv4 UID mapping breaks with AUTH_UNIX

Why NFSv4 uid/gid mapping doesn’t work with AUTH_UNIX (AUTH_SYS)

First of all NFSv4 is a great improvement on v3 a good job overall. Congratulations to the design team.
One of the potentially great features of v4 is id mapping which supposedly resolves the common problem of a user who has different uids (and gids) on different systems but wants to use NFS file sharing between them.
This problem used to be avoidable in a closed network where the admin controlled all machines. But increasingly laptops and otherwise heterogenous machines are being connected and the sysadmin (if there ever was one) is nolonger able to control everything.
Suppose for example one wants to use NFS in a small office or home environment where there are no hoards of evil doers attempting to enter your system (a debatable point with modern internet access and minimal firewalls).
Current NFS is just too hard in most cases so users resort to CIFS/Samba for example.

A quick recap on NFS authentication (actually RPC authentication which NFS is built upon).
NFS v2/v3:
  • AUTH_NONE – clients are connected a “anonymous” users – normally very restricted access
  • AUTH_UNIX (aka AUTH_SYS) – security via uid/gid equality between client and server.
  • AUTH_DH (aka AUTH_DES) public/private key security
  • AUTH_KERB – complex but higher security trust network.

NFSv4 in addition to the above offers the newer secure RPC mechanism:
  • RPCSEC_GSS a generic secure RPC authentication/encryption mechanism that offers Kerberos as one option.

NFSv4 does work in complex environments (eg NFSv4 + Kerberos + optionally LDAP/NIS etc). But any envionment that uses Kerberos etc is unfortunately by definition complex at the moment.
Requiring the flexibility and power of Kerberos to make NFS v4 work well is just too much for many admins.
Unix level security AUTH_UNIX is simple, based on uid and gid it is potentially enough security for most small intranets.
Now if the admin has complete control over all the client machines on the network then AUTH_UNIX can work (as it does in NFS v3 and before), but increasingly users want to connect personal laptops and other machines that the admin may not have complete control over. The NFS working group recognised this and added the concept of “id mapping”.
Let’s take a simple example.

Fred has a Mac that he wants to use on the company/home intranet that has simple security requirements (ie only user fred can access fred’s files). He wants access to his files on the Linux/Solaris server via NFS v4.
When fred set up his mac he created a user “fred” (mac ’shortname’) and by default the mac created his uid = 501 and gid = 20.
(Yes he probably could change his uid but that’s not the point here.)
Fred wants to connect to the server. The intranet administrator set up a matching username on the server also called fred (if this can’t be done one enters the domain of NIS/LDAP which we are not discussing now – so assume it is no problem having matching usernames).
But the server can’t adapt to every user’s whim on the matter of uids and gids so on the server fred is assigned a uid = 1003 and gid=10.

Prior to NFSv4 fred was out of luck. Mismatched uid/gid = no (or limited) access unless all files were made world readable/writable or with anonymous access which rather defeats the point.
NFSv4 and AUTH_SYS security however promises uid<->username mapping (and similar for groups). This simple but clever idea immediately resolves the uid mismatch problem. Provided username “fred” exists on both client and server (a simpler problem) the NFSv4 server and clients will convert between local uids and only talk usernames (and groupnames) over the wire.
So files created by fred on the server (uid=1003) will have its ownership reported over the wire as “fred” and the client will then translate this to uid 501. Thus ‘ls -l’ for example works beautifully whether run on local or remotely mounted files.
The problems start when we want to access the file contents or modify a file/directory and suddenly we get ‘permission denied’ type messages. Now NFS itself doesn’t do the security authentication but delegates it down to the underlying RPC mechanism.

Ok so we move down a level and look at RPC’s security. Well AUTH_SYS on RPC is just as it has been for the last umpteen years – based on uid/gid. The problem is these uids/gids are sent over the wire (just as they always have been).
“But”, says you, “Isn’t this what the whole NFSv4 id mapping feature was meant to fix!”
Ahh – there’s the rub.
RPC hasn’t been augmented to support such mapping.
Since RPC still send’s uid/gid over the wire the whole uid<->username mapping seems pretty useless in practice for the above common scenario (if you control the entire network then uids and gids are typically the same and there is no matching problem in the first place).
Now of course many programs other than NFS rely on RPC, which is also designed for heterogeneous environments so it would not be appropriate to just change how RPC works (and not strictly in the scope of NFSv4). But what would IMHO be sensible is to have a new mode of security based on uid<->name mapping. Let’s call it AUTH_NAME that works just as the NFSv4 uid<->username mapping works. Then simple NFSv4 would be usable.

Me thinks CIFS/Samba will be around for some time to come….

  • + : A leading plus sign indicates that this word must be present in every object returned.
  • - : A leading minus sign indicates that this word must not be present in any row returned.
  • By default (when neither plus nor minus is specified) the word is optional, but the object that contain it will be rated higher.
  • < > : These two operators are used to change a word's contribution to the relevance value that is assigned to a row.
  • ( ) : Parentheses are used to group words into subexpressions.
  • ~ : A leading tilde acts as a negation operator, causing the word's contribution to the object relevance to be negative. It's useful for marking noise words. An object that contains such a word will be rated lower than others, but will not be excluded altogether, as it would be with the - operator.
  • * : An asterisk is the truncation operator. Unlike the other operators, it should be appended to the word, not prepended.
  • " : The phrase, that is enclosed in double quotes ", matches only objects that contain this phrase literally, as it was typed.


Related Sites