Partially incorrect uid mapping with nfs4/idmapd/ldap-auth
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Fedora |
Won't Fix
|
Critical
|
|||
linux (Ubuntu) |
Fix Released
|
Low
|
Unassigned | ||
Trusty |
Fix Released
|
Low
|
Dariusz Gadomski | ||
Utopic |
Fix Released
|
Low
|
Dariusz Gadomski | ||
nfs-utils (Debian) |
Fix Released
|
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.
Important lines in /etc/idmapd.conf :
domain=
[Translation]
Method=nsswitch.
In /etc/default/
NEED_IDMAPD=yes
In /etc/default/
RPCNFSDCOUNT=75
RPCMOUNTDOPTS=
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=
[Translation]
Method=nsswitch
In /etc/default/
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=
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 '<email address hidden>' domain 'my-domain.org': resulting localname 'user109'
rpc.idmapd[561]: nfs4_name_to_uid: nsswitch-
rpc.idmapd[561]: nfs4_name_to_uid: final return value is 0
rpc.idmapd[561]: Client 0: (user) name "<email address hidden>" -> id "55101"
rpc.idmapd[561]: nfs4_name_to_uid: calling nsswitch-
rpc.idmapd[561]: nss_getpwnam: name '<email address hidden>' domain 'my-domain.org': resulting localname 'user102'
rpc.idmapd[561]: nfs4_name_to_uid: nsswitch-
rpc.idmapd[561]: nfs4_name_to_uid: final return value is 0
rpc.idmapd[561]: Client 0: (user) name "<email address hidden>" -> 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.
description: | updated |
Changed in nfs-utils (Ubuntu): | |
assignee: | nobody → Dariusz Gadomski (dgadomski) |
Changed in nfs-utils (Debian): | |
status: | Unknown → Incomplete |
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → Low |
Changed in linux (Ubuntu Utopic): | |
status: | Confirmed → Won't Fix |
Changed in linux (Ubuntu Trusty): | |
status: | New → Won't Fix |
importance: | Undecided → Low |
Changed in nfs-utils (Debian): | |
status: | Incomplete → Confirmed |
Changed in nfs-utils (Debian): | |
status: | Confirmed → Fix Released |
Changed in linux (Ubuntu Utopic): | |
status: | Won't Fix → In Progress |
Changed in linux (Ubuntu Trusty): | |
status: | Won't Fix → In Progress |
description: | updated |
tags: | added: cts |
no longer affects: | nfs-utils (Ubuntu) |
no longer affects: | nfs-utils (Ubuntu Trusty) |
no longer affects: | nfs-utils (Ubuntu Utopic) |
Changed in linux (Ubuntu Trusty): | |
assignee: | nobody → Dariusz Gadomski (dgadomski) |
Changed in linux (Ubuntu Utopic): | |
assignee: | nobody → Dariusz Gadomski (dgadomski) |
Changed in linux (Ubuntu): | |
status: | Confirmed → Fix Released |
Changed in linux (Ubuntu Utopic): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Trusty): | |
status: | In Progress → Fix Committed |
tags: | added: verification-needed-trusty |
tags: | added: verification-needed-utopic |
tags: |
added: verification-done-trusty verification-done-utopic removed: verification-needed-trusty verification-needed-utopic |
Changed in linux (Ubuntu Utopic): | |
status: | Fix Committed → Fix Released |
status: | Fix Committed → Fix Released |
Changed in linux (Ubuntu Trusty): | |
status: | Fix Committed → Fix Released |
status: | Fix Committed → Fix Released |
Changed in nfs-utils (Debian): | |
status: | Fix Released → Confirmed |
Changed in fedora: | |
importance: | Unknown → Critical |
status: | Unknown → Won't Fix |
Changed in nfs-utils (Debian): | |
status: | Confirmed → Fix Released |
David,
Would it make sense to patch the kernel so the maxkeys/ root_maxkeys are set to a more reasonable value?