Comment 20 for bug 966734

Having just spent several days trying to get to the root cause of this id-mapping issue I am strongly inclined to agree with Ancoron regarding the forced usage of UID & GID with AUTH_SYS.
I have exactly the issue he describes. This is a small home setup and I do not have nor do I desire to set-up and configure a Kerberos infrastructure. I have 3 OSs running. Linux OSX and Windows. The Windows client is a corner case where I am forced to make it emulate a server side UID & GID as it lacks NFSv4 anyway. However the OSX machines and Linux machines where set-up a different times. They have different UID & GIDs for the same named user. I made the move to NFS4 as I was under the impression that id-mapping would allow a setup where the UIDs & GIDs of these machines could stay different to those on the server and by running id-mapping all client requests would contain the string based names to enable the server to map these incoming request to a local UID & GID. No such luck.

Having watched carefully the exchanges on the wire I would suggest that the current implementation is neither working nor consistent in this scenario.

If id-mapping is configured on the server /sys/module/nfsd/parameters/nfs4_disable_idmapping = 0 and the same is also configured on the client in : /sys/module/nfs/parameters/nfs4_disable_idmapping = 0
The client sends all its request only ever using UID & GID in the RPC header. The NFS4 Attr mask Owner and Owner_Group are always blank.
However replies from the server to these same requests always have these NFS4 attr containing the mapped strings. The client honours this and maps correctly to the required client side UID & GID using a call to nfsidmap, which subsequently call nsswitch:
nfs4_name_to_gid: nsswitch->name_to_gid returned 0

So essentially we have one way mapping, working correctly from Server to Client, but not available from Client to Server.

I can understand that there may well be security implications for a simple mapping scenario, but to be blunt, who cares! these are my machines and my network, its not large and I'm not paranoid. If I was truly worried about security then I would implement Kerberos, but I am not.

However due to the fact that the client does not offer NFS4 attr as the string name, the server can never perform the same mapping in the client to server direction.

This forces either matching UID & GID on all clients and server, or separate UID & potentially GIDs on each machine, or use of all_squash in the export to crunch all client to server requests into one user or still further per client IP address based exports with different all_squash options. All of these are sub-optimal.

I would be interested to know if anyone is familiar enough with the RFCs to know whether the use of AUTH_SYS within the RPC header specifically precludes the use of id-mapping by the server for incoming requests. If this is not strictly forbidden then why could the use of AUTH_SYS with string based NFS4 attr not be a perfectly valid possibility. IMHO it would offer flexibility better than what is currently available and much simpler for the home or less security concerned user.