Hide Forgot
Description of problem: This is a dependency for fixing bug #720230. It was found during QE testing of #720230, but it is a slightly different issue that needs a different fix. Version-Release number of selected component (if applicable): nss-pam-ldapd-0.7.5-10.el6 How reproducible: always Steps to Reproduce: 1. Create a user with a large UID value in the directory dn: uid=ldaptestuser,ou=people,dc=my-domain,dc=com uid: ldaptestuser cn: ldaptestuser objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword:: e01ENX1DMDU2RGwvb1N0TmZ0Zmxibk82c2VRPT0= shadowLastChange: 14460 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 3123456789 gidNumber: 3123456789 homeDirectory: /home/ gecos: ldaptestuser 2. getent passwd ldaptestuser Actual results: 32b: ldaptestuser:x:2147483647:2147483647:ldaptestuser:/home/:/bin/bash 64b: ldaptestuser:x:3123456789:3123456789:ldaptestuser:/home/:/bin/bash Expected results: 32b: ldaptestuser:x:3123456789:3123456789:ldaptestuser:/home/:/bin/bash 64b: ldaptestuser:x:3123456789:3123456789:ldaptestuser:/home/:/bin/bash Additional info: The fix is available upstream: http://arthurdejong.org/viewvc/nss-pam-ldapd?revision=1523&view=revision http://arthurdejong.org/viewvc/nss-pam-ldapd?revision=1524&view=revision http://arthurdejong.org/viewvc/nss-pam-ldapd?revision=1528&view=revision A first-pass on the backport was attached to the original BZ - https://bugzilla.redhat.com/attachment.cgi?id=520768&action=diff
The root cause of this bug was using "strtol" for values that could overflow LONG_MAX in 32bit architectures.
Nalin reviewed the patch in https://bugzilla.redhat.com/attachment.cgi?id=520768&action=diff and had one comment - we should make sure to use explicit base 10 when converting the attribute values to native C integer types. A patch that does this is currently on review upstream - http://lists.arthurdejong.org/nss-pam-ldapd-users/2011/msg00227.html
The last amendment was accepted upstream: http://arthurdejong.org/viewvc/nss-pam-ldapd?revision=1547&view=revision
Created attachment 525770 [details] A proposed patch including the explicit base 10
Nalin, does what patch work for you? If so, I'll commit.
(In reply to comment #5) > Nalin, does what patch work for you? If so, I'll commit. ..that patch..
Yes, looks alright from here.
Jakub, your patches solved most of gid/uid issues, but there is still one remaining - when gid/uid is negative: ldapsearch: dn: uid=user-101,ou=people,dc=my-domain,dc=com uid: uuser-101 uid: user-101 cn: user-101 objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword:: e01ENX1DMDU2RGwvb1N0TmZ0Zmxibk82c2VRPT0= shadowLastChange: 14460 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: -101 gidNumber: -101 homeDirectory: /home/ gecos: user-101 getent: user-101:x:4294967195:4294967195:user-101:/home/:/bin/bash From my point of view, it should behave the same way as if uid/gid is bigger than 2**32-1 (i.e. getent should not exit with 0).
Aforementioned issue happens on i686 only, on 64b system negative uid/git work as expected (i.e. they are invalid and not returned by getent).
I have discussed this with Jakub today and it will be resolved in this bug (the fix of this bug is not complete). ETA for the fix completion is next week. And since QA move is over now, I am setting this back to ASSIGNED state just to indicate that a ball is now in Jakub's hands :).
What about zero uid / gid? It is allowed for a non-root user? That is, when there is a posixAccount user in LDAP with uid = gid = 0, should getent return its record or not? Are there any applications verifying superuser by its uid only? ldapsearch: dn: uid=user0,ou=people,dc=my-domain,dc=com uid: uuser0 uid: user0 cn: user0 objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword:: e01ENX1DMDU2RGwvb1N0TmZ0Zmxibk82c2VRPT0= shadowLastChange: 14460 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 0 gidNumber: 0 homeDirectory: /home/ gecos: user0 getent: user0:x:0:0:user0:/home/:/bin/bash
I don't think there is any document technically forbidding uid=0. That said, it is unwise, to say the least, to store UID 0 in LDAP. If I remember correctly, sssd would error out on an entry like this.
As you noted, it's valid data to have in a directory server, and it isn't out of range of uid_t, so it should be handled like any other entry. A client implementation can choose to ignore that entry, but that's not something that nslcd does as part of its nsswitch functions.
Thank you both for answers, your opinion sounds very reasonable.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1705.html