Bug 741362 - Large UID values can overflow on 32bit architectures
Summary: Large UID values can overflow on 32bit architectures
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss-pam-ldapd
Version: 6.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On:
Blocks: 720230 748554
TreeView+ depends on / blocked
 
Reported: 2011-09-26 16:54 UTC by Jakub Hrozek
Modified: 2018-11-26 19:11 UTC (History)
5 users (show)

Fixed In Version: nss-pam-ldapd-0.7.5-14.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 17:36:25 UTC


Attachments (Terms of Use)
A proposed patch including the explicit base 10 (6.98 KB, patch)
2011-09-30 13:16 UTC, Jakub Hrozek
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1705 normal SHIPPED_LIVE nss-pam-ldapd bug fix and enhancement update 2011-12-06 01:02:30 UTC

Description Jakub Hrozek 2011-09-26 16:54:06 UTC
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

Comment 1 Jakub Hrozek 2011-09-26 16:59:30 UTC
The root cause of this bug was using "strtol" for values that could overflow
LONG_MAX in 32bit architectures.

Comment 2 Jakub Hrozek 2011-09-29 16:14:20 UTC
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

Comment 3 Jakub Hrozek 2011-09-30 13:15:05 UTC
The last amendment was accepted upstream:
http://arthurdejong.org/viewvc/nss-pam-ldapd?revision=1547&view=revision

Comment 4 Jakub Hrozek 2011-09-30 13:16:45 UTC
Created attachment 525770 [details]
A proposed patch including the explicit base 10

Comment 5 Jakub Hrozek 2011-09-30 13:17:31 UTC
Nalin, does what patch work for you? If so, I'll commit.

Comment 6 Jakub Hrozek 2011-09-30 13:17:53 UTC
(In reply to comment #5)
> Nalin, does what patch work for you? If so, I'll commit.

..that patch..

Comment 7 Nalin Dahyabhai 2011-10-03 15:30:18 UTC
Yes, looks alright from here.

Comment 10 Ondrej Moriš 2011-10-11 10:08:14 UTC
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).

Comment 11 Ondrej Moriš 2011-10-11 10:33:49 UTC
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).

Comment 13 Ondrej Moriš 2011-10-11 14:19:51 UTC
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 :).

Comment 14 Ondrej Moriš 2011-10-12 09:50:21 UTC
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

Comment 15 Jakub Hrozek 2011-10-12 13:45:28 UTC
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.

Comment 16 Nalin Dahyabhai 2011-10-12 15:27:26 UTC
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.

Comment 17 Ondrej Moriš 2011-10-12 18:32:29 UTC
Thank you both for answers, your opinion sounds very reasonable.

Comment 21 errata-xmlrpc 2011-12-06 17:36:25 UTC
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


Note You need to log in before you can comment on or make changes to this bug.