Bug 720230
| Summary: | nslcd truncates large gid numbers | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | raal.goff | ||||||||
| Component: | nss-pam-ldapd | Assignee: | Nalin Dahyabhai <nalin> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | 6.0 | CC: | dpal, jhrozek, omoris, prc | ||||||||
| Target Milestone: | rc | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | nss-pam-ldapd-0.7.5-8.el6 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2011-12-06 17:36:16 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | 741362 | ||||||||||
| Bug Blocks: | |||||||||||
| Attachments: |
|
||||||||||
Nalin, what is the maximum allowed uid, gid value on 32/64 system? LONG_MAX (2^31-1 [32b] resp. 2^63-1 [64b])? If so, then getent reports for the following user record are different: # ldaptestuser, people, my-domain.com 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 32b: ldaptestuser:x:2147483647:2147483647:ldaptestuser:/home/:/bin/bash 64b: ldaptestuser:x:3123456789:3123456789:ldaptestuser:/home/:/bin/bash It is correct, right? It should be an unsigned 32-bit number everywhere. In any case, if you're getting a value that's different from what's in the directory, we have a (slightly different) problem. Unfortunately, on i386 it is signed 32-bit number (2147483647). On the other architectures (s390x, ppc64, x86_64) it is unsigned 32-bit number (4294967295). I think we're overflowing on values above LONG_MAX, which is much larger on the 64-bit arches you've listed. Created attachment 519450 [details]
A proposed patch
This patch uses strtoul() instead of strtol() for GIDs and UIDs
Upstream accepted a slightly different variant of the patch in three different commits that followed a discussion: 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 Created attachment 520768 [details]
backported upstream patches
The patch back ports the appropriate parts of upstream commits merged into one patch.
I have tried same values of UID / GID, everything valid (i.e. 0 - 2^32-1) works fine, but I am not sure what is the correct behaviour for invalid values, e.g. * negative: dn: uid=ldaptestuserE,ou=people,dc=my-domain,dc=com uid: ldaptestuserE cn: ldaptestuserE objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword:: e01ENX1DMDU2RGwvb1N0TmZ0Zmxibk82c2VRPT0= shadowLastChange: 14460 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: -1048576 gidNumber: -1048576 homeDirectory: /home/ gecos: ldaptestuser ldaptestuserE:x:4293918720:4293918720:ldaptestuser:/home/:/bin/bash * more than 2^32 - 1: dn: uid=ldaptestuserC,ou=people,dc=my-domain,dc=com uid: ldaptestuserC cn: ldaptestuserC objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword:: e01ENX1DMDU2RGwvb1N0TmZ0Zmxibk82c2VRPT0= shadowLastChange: 14460 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 4294967296 gidNumber: 4294967296 homeDirectory: /home/ gecos: ldaptestuser ldaptestuserC:x:0:0:ldaptestuser:/home/:/bin/bash Are these values correct? Isn't 0 UID dangerous in the second case? (In reply to comment #10) > * more than 2^32 - 1: > > dn: uid=ldaptestuserC,ou=people,dc=my-domain,dc=com > uid: ldaptestuserC > cn: ldaptestuserC > objectClass: account > objectClass: posixAccount > objectClass: top > objectClass: shadowAccount > userPassword:: e01ENX1DMDU2RGwvb1N0TmZ0Zmxibk82c2VRPT0= > shadowLastChange: 14460 > shadowMax: 99999 > shadowWarning: 7 > loginShell: /bin/bash > uidNumber: 4294967296 > gidNumber: 4294967296 > homeDirectory: /home/ > gecos: ldaptestuser > > ldaptestuserC:x:0:0:ldaptestuser:/home/:/bin/bash > > Are these values correct? Isn't 0 UID dangerous in the second case? This definitely sounds wrong. Did you test with the patch from comment #9 or upstream version? Note that the patch for this bug (and bug #716822) only solves the "drops digits from the value" bug, and doesn't cover the range problems Jakub's worked on. We need to be track those separately. (In reply to comment #12) > Note that the patch for this bug (and bug #716822) only solves the "drops > digits from the value" bug, and doesn't cover the range problems Jakub's worked > on. We need to be track those separately. Done: https://bugzilla.redhat.com/show_bug.cgi?id=741362 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 |
Created attachment 512136 [details] Patch for fix Description of problem: RHEL 6, large gid's in from passwd lookups get truncated, so for a user: uid: username uidNumber: 1412600003 gidNumber: 1412600003 the gidNumber would get truncated to 141260000 This presents itself as an error of 'id: cannot find name for group ID 141260000' when the user logs in. It looks like the buffer for the gidNumber is too small for the number. The attached patch increases the buffer size to allow for longer gidNumbers. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. Create an LDAP user with a gid of 1412600000 or higher 2. Log into machine using ldap credentials 3. type id to see how group number is truncated Actual results: gid is truncated Expected results: gid should be correct Additional info: I guess this could be used to impersonate a different group. The attached patch fixes the issue. The same patch has been submitted upstream.