← Back to team overview

kernel-packages team mailing list archive

[Bug 1124250] Re: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth

 

If I understood correctly, historically there have been two
independently developed alternative user-space mechanisms that can
perform uid <-> user name lookups for the Linux NFSv4 implementation in
the kernel, one from the University of Michigan and one from NetApp:

A)  /usr/sbin/rpc.idmapd runs as a daemon and listens to some pipe in
/run/rpc_pipefs, and kernel sends requests via that pipe

B) kernel executes for each request the command /sbin/request-key, which
according to /etc/request-key.* calls nfsidmap, which then answers to
the kernel via the add_key() and keyctl() system calls

Which of these is meant to be used on Ubuntu 145.04 LTS, and how to I
specify and verify that choice?

I'm asking, because I get syslog messages from rpc.idmapd such as

May  7 13:51:11 dirac nfsidmap[10738]: nss_getpwnam: name 'nobody' does
not map into domain 'cl.cam.ac.uk'

and at the same time I also find nfsidmap-related keys in

$ sudo cat /proc/keys
[...]
2c6194e5 I--Q-N-     1  26s 3b010000     0     0 id_resolv uid:root@xxxxxxxxx
2d5a0c25 I--Q-N-     1  28s 3b010000     0     0 id_resolv uid:mgk25@xxxxxxxxx
2e025d97 I--Q---     1   9m 3b010000     0     0 id_legacy uid:mgk25@xxxxxxxxx: 5
2e463b17 I--Q---     1   9m 3b010000     0     0 id_legacy uid:nad10@xxxxxxxxx: 5
331c87da I--Q-N-     1  28s 3b010000     0     0 id_resolv gid:ncc25@xxxxxxxxx
33955fd4 I--Q---     1   9m 3b010000     0     0 id_legacy gid:wednesday@xxxxxxxxx: 4
36702b00 I--Q-N-     1  28s 3b010000     0     0 id_resolv gid:wednesday@xxxxxxxxx
376c94e9 I--Q-N-     1  28s 3b010000     0     0 id_resolv uid:www@xxxxxxxxx
37ef3e9a I--Q---     1   9m 3b010000     0     0 id_legacy gid:wwwupdate@xxxxxxxxx: 4
3c332878 I--Q---     1   9m 3b010000     0     0 id_legacy gid:nobody: 6
3e585863 I------     1 perm 1f030000     0     0 keyring   .id_resolver: 36
3fbf548d I------     1 perm 1f0b0000     0     0 keyring   .system_keyring: 1

Are both these idmap systems really supposed to be active at the same
time?

What is the difference between the id_resolv and id_legacy key types?

What does it mean to have negative id_resolv and non-negative id_legacy
keys at the same time, as above?

Where is all this NFSv4 uid/gid translation mechanics documented?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1124250

Title:
  Partially incorrect uid mapping with nfs4/idmapd/ldap-auth

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Fix Released
Status in linux source package in Utopic:
  Fix Released
Status in nfs-utils package in Debian:
  Fix Released
Status in Fedora:
  Unknown

Bug description:
  [Impact]

   * This bug is likely to cause an incorrect UID/GID mapping for NFS
  shares in case of large numbers of differend UIDs/GIDs or in case of
  expired UID/GID mappings (stored as keys in the kernel).

  [Test Case]

   1. Setup a nfs4 server exporting /home with a large number of different users and ldap-based authentication.
   2. Mount the share on a ldap-connected client machine.
   3. List the mounted /home directory.
   4. Wait more than 10 minutes (the default key expiration time) and list it again with ls -l.

  Expected result - all directories are listed with correct UIDs/GIDs.
  Actual result - some of the directories may be listed with incorrect UID/GID of 4294967294.

  [Regression Potential]

   * This issue has been merged upstream in the 3.18 kernel and is also
  present in Debian's 3.16 kernel.

  [Other Info]

  * Original bug description:

  I'm running a nfs4 server exporting a directory /home (ext4,usrquota). This server is running Ubuntu 12.04 amd64(up-to-date). This directory is handling 662 homedirs for ldap authenticated users.
  /etc/exports is :
  /exports  192.168.0.0/24(rw,fsid=0,no_subtree_check)

  Important lines in /etc/idmapd.conf :
  domain=my-domain.org

  [Translation]
  Method=nsswitch.

  In /etc/default/nfs-common :
  NEED_IDMAPD=yes

  In /etc/default/nfs-kernel-server :
  RPCNFSDCOUNT=75
  RPCMOUNTDOPTS=--manage-gids

  2 Clients (rhel6 x86 & Ubuntu 12.04.2 i686) are mounting this nfs4 exported directory with no problems :
  When doing ls -l /home on this clients, I have :
  ...
  drwx------   4 user100 oldusers     4096 sept. 21  2011 user100
  drwx------   4 user101 oldusers     4096 sept. 21  2011 user101
  drwx------  37 user102 oldusers     4096 oct.   1 19:06 user102
  drwx------  36 user103 users        4096 févr. 5 21:08 user103
  drwx------  36 user104 users        4096 févr. 8 14:03 user104
  drwx------  30 user105 users        4096 févr. 4 18:01 user105
  drwx------  28 user106 oldusers     4096 oct.   5  2011 user106
  drwx------  37 user107 oldusers     4096 janv.  8 14:52 user107
  drwx------  31 user108 users        4096 déc.  4 11:52 user108
  drwx------   4 user109 oldusers     4096 sept. 21  2011 user109
  drwx--x--x  45 user110 oldusers     4096 janv. 22 15:53 user109
  drwx------  31 user111 users        4096 janv. 29 12:03 user110
  ...
  uid/gid mapping works fine, authldap works fine, ...

  All Clients running Ubuntu 12.10 i686  or  Ubuntu 12.10 amd64 are experiencing the same problem :
  The config files are the same that used in ubuntu 12.04.
  Auth ldap is correctly configured, user can log in.

  This is the /etc/fstab entry for /home :
  192.168.0.1:/     /home     nfs      rw,nfsvers=4     0  0

  Important lines in /etc/idmapd.conf :
  domain=my-domain.org
  [Translation]
  Method=nsswitch

  In /etc/default/nfs-common :
  NEED_IDMAPD=yes

  /etc/nsswitch.conf is :
  passwd: files ldap
  group: files ldap
  shadow: files ldap

  When doing ls -l /home there is a strange problem :

  drwx------   4 4294967294 oldusers     4096 sept. 21  2011 user100
  drwx------   4 user101    oldusers     4096 sept. 21  2011 user101
  drwx------  37 user102    oldusers     4096 oct.   1 19:06 user102
  drwx------  36 4294967294 users        4096 févr. 5 21:08 user103
  drwx------  36 4294967294 users        4096 févr. 8 14:03 user104
  drwx------  30 4294967294 users        4096 févr. 4 18:01 user105
  drwx------  28 4294967294 oldusers     4096 oct.   5  2011 user106
  drwx------  37 4294967294 oldusers     4096 janv.  8 14:52 user107
  drwx------  31 4294967294 users        4096 déc.  4 11:52 user108
  drwx------   4 user109    oldusers     4096 sept. 21  2011 user109
  drwx--x--x  45 4294967294 oldusers     4096 janv. 22 15:53 user110
  drwx------  31 4294967294 users        4096 janv. 29 12:03 user111

  for  571 homedirs (this number varies at each reboot)/662, the owner is the value 4294967294. For the  91 remaining homedirs,
  the owner is correct. The gidnumber is correctly mapped for all (only  5 differents values used for gidNumber).

  In /var/log/syslog, I can see :

  For example : user110 is mapped as 4294967294.
  but the command "id user110" returns :
  uid=31124(user110) gid=666(oldusers) groupes=666(oldusers)

  user110 logs in (auth ldap) from tty1. He runs "ls -l /home/user110/"
  :

  drwxr-xr-x 8 4294967294 oldusers 4096 janv. 19  2012 Bureau
  drwxr-xr-x 3 4294967294 oldusers 4096 déc.   2  2011 Documents
  drwxr-xr-x 2 4294967294 oldusers 4096 déc.   2  2011 Images

  Then, he runs "touch /home/user110/test" :

  drwxr-xr-x 8 4294967294 oldusers 4096 janv. 19  2012 Bureau
  drwxr-xr-x 3 4294967294 oldusers 4096 déc.   2  2011 Documents
  drwxr-xr-x 2 4294967294 oldusers 4096 déc.   2  2011 Images
  drwxr-xr-x 2 4294967294 oldusers    0 févr. 13 16:01 test

  On the nfs server, If i do a ls -l in the same directory  :

  drwxr-xr-x 8 user110 oldusers 4096 janv.  19  2012 Bureau
  drwxr-xr-x 3 user110 oldusers 4096 déc.   2  2011 Documents
  drwxr-xr-x 2 user110 oldusers 4096 déc.   2  2011 Images
  drwxr-xr-x 2 user110 oldusers    0 févr. 13 16:01 test

  I can see that the "test" file is owned by the correct user.

  I've tried without & with nscd, same results.
  I've tried using sssd, libnss-sss & pam_sss for ldap auth and having exactly the same results :

  In /var/log/syslog, I have :
  ...
  rpc.idmapd[561]: nss_getpwnam: name 'user109@xxxxxxxxxxxxx' domain 'my-domain.org': resulting localname 'user109'
  rpc.idmapd[561]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0
  rpc.idmapd[561]: nfs4_name_to_uid: final return value is 0
  rpc.idmapd[561]: Client 0: (user) name "user109@xxxxxxxxxxxxx" -> id "55101"
  rpc.idmapd[561]: nfs4_name_to_uid: calling nsswitch->name_to_uid
  rpc.idmapd[561]: nss_getpwnam: name 'user102@xxxxxxxxxxxxx' domain 'my-domain.org': resulting localname 'user102'
  rpc.idmapd[561]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0
  rpc.idmapd[561]: nfs4_name_to_uid: final return value is 0
  rpc.idmapd[561]: Client 0: (user) name "user102@xxxxxxxxxxxxx" -> id "55199"
  ...
  only for the correctly mapped entries. No warnings or errors (rate limit disabled in rsyslog.conf) and verbosity set to 5 in idmapd.conf. It seems that rpc.idmapd never does mapping for other entries.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1124250/+subscriptions