← Back to team overview

kernel-packages team mailing list archive

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

 

stef: can you please check after you observe the problem if your key quota is not exceeded? You may do this with:
$ sudo cat /proc/key-users

This fix is known to solve the expired keys problem, but if the cause of
the issue you are experiencing is the capacity of the key quota  you may
have to extend it (please see comment #2).

Thanks!

-- 
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 Committed
Status in linux source package in Utopic:
  Fix Committed
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