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