RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 720230 - nslcd truncates large gid numbers
Summary: nslcd truncates large gid numbers
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss-pam-ldapd
Version: 6.0
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On: 741362
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-11 05:05 UTC by raal.goff
Modified: 2016-03-30 13:39 UTC (History)
4 users (show)

Fixed In Version: nss-pam-ldapd-0.7.5-8.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 17:36:16 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Patch for fix (303 bytes, text/plain)
2011-07-11 05:05 UTC, raal.goff 		no flags Details
A proposed patch (2.13 KB, patch)
2011-08-23 12:14 UTC, Jakub Hrozek 		no flags Details | Diff
backported upstream patches (6.84 KB, patch)
2011-08-31 09:05 UTC, Jakub Hrozek 		no flags Details | Diff
Show Obsolete (1) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 716822 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHBA-2011:1705 0 normal SHIPPED_LIVE nss-pam-ldapd bug fix and enhancement update 2011-12-06 01:02:30 UTC

Internal Links: 716822

Description raal.goff 2011-07-11 05:05:49 UTC 
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.
Comment 3 Ondrej Moriš 2011-08-19 16:23:29 UTC 
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?
Comment 4 Nalin Dahyabhai 2011-08-19 16:46:13 UTC 
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.
Comment 5 Ondrej Moriš 2011-08-19 17:08:30 UTC 
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).
Comment 6 Nalin Dahyabhai 2011-08-19 17:33:08 UTC 
I think we're overflowing on values above LONG_MAX, which is much larger on the 64-bit arches you've listed.
Comment 7 Jakub Hrozek 2011-08-23 12:14:10 UTC 
Created attachment 519450 [details]
A proposed patch

This patch uses strtoul() instead of strtol() for GIDs and UIDs
Comment 8 Jakub Hrozek 2011-08-31 09:03:26 UTC 
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
Comment 9 Jakub Hrozek 2011-08-31 09:05:14 UTC 
Created attachment 520768 [details]
backported upstream patches

The patch back ports the appropriate parts of upstream commits merged into one patch.
Comment 10 Ondrej Moriš 2011-09-21 06:01:41 UTC 
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?
Comment 11 Jakub Hrozek 2011-09-21 12:03:21 UTC 
(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?
Comment 12 Nalin Dahyabhai 2011-09-21 15:14:21 UTC 
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.
Comment 13 Jakub Hrozek 2011-09-26 16:55:50 UTC 
(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
Comment 15 errata-xmlrpc 2011-12-06 17:36:16 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.