[Bug 966734] Re: nfs4+idmap does not map uids correctly when using AUTH_SYS

[Aidan Walton]

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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to nfs-utils in Ubuntu.
https://bugs.launchpad.net/bugs/966734

Title:
  nfs4+idmap does not map uids correctly when using AUTH_SYS

Status in nfs-utils package in Ubuntu:
  Triaged

Bug description:
  I've observed this bug on Ubuntu Precise (beta) and Oneiric, and also on Debian Squeeze and Debian Testing.
  (Kernel versions 2.6.32, 3.0.0 and 3.2.0)
  I've found numerous forum posts around the internet from confused users, but no solutions.

  The bug in question involves using nfs v4 with the idmapd, with users with the same username but differing uids across the client and server. The idmapping appears to have worked, until you try to write to the directories, at which point it skips the idmapping.
  This is a security issue as it will allow users to access files owned by other users unexpectedly.

  When listing files or directories on the client, the directories show
  up as owned by your local user, however attempting to write will
  result in a Permission Denied error. If you go back to the server and
  chown the directory to be owned by the uid used on the client, then
  the client will see the directory as owned by the incorrect user --
  but WILL be able to write to it!

  The log files for idmapd on both client and server appear to indicate
  that things are working correctly. eg:

  Server's syslog: rpc.idmapd[777]: Server : (user) id "2012" -> name "postie at localdomain"
  Client's syslog: rpc.idmapd[870]: Client 0: (user) name "postie at localdomain" -> id "2014"

  Running commands on the client:
  $ getent passwd postie
  postie:x:2014:2014::/home/postie:/bin/bash
  $ cd /srv/test
  $ ls -l
  drwxr-xr-x 2 postie root 4096 Mar 28 11:48 postie
  $ ls -ln
  drwxr-xr-x 2 2014 0 4096 Mar 28 11:48 postie
  $ touch postie/foo
  touch: cannot touch `postie/foo': Permission denied

  
  To prove that the mount *is* mounted read-write, I'll change the ownership of the directory on the server to uid 2014, rather than the postie user there (who has uid 2012).

  Now I run some commands on the client again:
  $ ls -l
  drwxr-xr-x 2 nobody root 4096 Mar 28 11:48 postie
  $ ls -ln
  drwxr-xr-x 2 65534 0 4096 Mar 28 11:48 postie
  $ touch postie/foo
  # It succeeds!

  
  Any thoughts on this, or if there's a better place to report this bug?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/966734/+subscriptions