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 742295 - Use an explicit base 10 when converting uidNumber to integer
Summary: Use an explicit base 10 when converting uidNumber to integer
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.2
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Stephen Gallagher
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks: 748554 748881
TreeView+ depends on / blocked
 
Reported: 2011-09-29 15:46 UTC by Jakub Hrozek
Modified: 2020-05-02 16:25 UTC (History)
6 users (show)

Fixed In Version: sssd-1.5.1-55.el6
Doc Type: Bug Fix
Doc Text:
Cause: When converting string values returned by LDAP, SSSD used conversion with implicit number base, leading to auto detection which base should be used. Consequence: In case UID or GID value returned from LDAP started with zero, the number would be considered octal and after conversion, a wrong value would be used. Fix: Explicit 10 base is now used for conversion. Result: UIDs and GIDs aren't converted to wrong values. SSSD either converts them using base 10 or errors out.
Clone Of:
: 748881 (view as bug list)
Environment:
Last Closed: 2011-12-06 16:40:42 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
FedoraHosted SSSD 1013 0 None None None Never
Github SSSD sssd issues 2055 0 None None None 2020-05-02 16:25:40 UTC
Red Hat Product Errata RHBA-2011:1529 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2011-12-06 00:50:20 UTC

Description Jakub Hrozek 2011-09-29 15:46:37 UTC 
Description of problem:
SSSD uses strtol/strtoul/strtoull calls to convert LDAP attributes to native C integer types. The third parameter of these functions is the base. If the default base "0" is used, then the base is determined by the number prefix - 015 would be octal, 0x15 would be hexadecimal, 15 would be decimal etc.

The biggest problem might be UID and GID values -- if someone accidentally prefixed the UID number attribute with a 0, the number would be converted as if it was octal base and converted to a completely different UID number.

For safety's sake we should set the base to 10 and error out if a different base is found.

Version-Release number of selected component (if applicable):
sssd-1.5.1-52.el6

How reproducible:
always

Steps to Reproduce:
1. create a user with a UID attribute prefixed so it looks like a non-decimal base
2. getent passwd user
  
Actual results:
getent reports a different number than in directory

Expected results:
the number should be the same

Additional info:
Many LDAP server schemas would reject non-decimal values of the uidNumber attribute of the posixUser objectlass. A workaround when reproducing the bug might be to remap the attribute to a different one using the "ldap_user_uid_number" attribute.
Comment 1 Jakub Hrozek 2011-09-29 16:15:26 UTC 
It is worth noting that the same change is being done in nss-pam-ldapd for 6.2

See https://bugzilla.redhat.com/show_bug.cgi?id=741362#c2 for more details.
Comment 2 Stephen Gallagher 2011-09-30 11:55:12 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1013
Comment 4 Kaushik Banerjee 2011-10-17 14:31:32 UTC 
Steps to verify:

1. Add a user with following attributes:
dn: uid=kau28,ou=Users,dc=example,dc=com
changetype: add
objectClass: posixAccount
uidNumber: 282828
gidNumber: 282828
homeDirectory: /home/kau28
gecos: 0282828
loginShell: /bin/bash
userPassword: Secret123
objectClass: person
sn: kau28
cn: kaushik28
objectClass: organizationalPerson
objectClass: inetOrgPerson
givenName: kau28

2. Configure sssd with:
ldap_user_uid_number = gecos

3. # getent -s sss passwd kau28
kau28:*:282828:282828:kaushik28:/home/kau28:/bin/bash


Verified in version:
# rpm -qi sssd | head
Name        : sssd                         Relocations: (not relocatable)
Version     : 1.5.1                             Vendor: Red Hat, Inc.
Release     : 58.el6                        Build Date: Sat 15 Oct 2011 12:14:26 AM IST
Install Date: Mon 17 Oct 2011 11:56:24 AM IST      Build Host: x86-001.build.bos.redhat.com
Group       : Applications/System           Source RPM: sssd-1.5.1-58.el6.src.rpm
Size        : 3599114                          License: GPLv3+
Signature   : (none)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://fedorahosted.org/sssd/
Summary     : System Security Services Daemon
Comment 5 Jan Zeleny 2011-10-27 12:03:07 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: When converting string values returned by LDAP, SSSD used conversion with implicit number base, leading to auto detection which base should be used.
Consequence: In case UID or GID value returned from LDAP started with zero, the number would be considered octal and after conversion, a wrong value would be used.
Fix: Explicit 10 base is now used for conversion.
Result: UIDs and GIDs aren't converted to wrong values.
Comment 6 Jakub Hrozek 2011-10-27 14:22:45 UTC 
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,4 +1,4 @@
 Cause: When converting string values returned by LDAP, SSSD used conversion with implicit number base, leading to auto detection which base should be used.
 Consequence: In case UID or GID value returned from LDAP started with zero, the number would be considered octal and after conversion, a wrong value would be used.
 Fix: Explicit 10 base is now used for conversion.
-Result: UIDs and GIDs aren't converted to wrong values.+Result: UIDs and GIDs aren't converted to wrong values. SSSD either converts them using base 10 or errors out.
Comment 7 errata-xmlrpc 2011-12-06 16:40:42 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-1529.html
Note You need to log in before you can comment on or make changes to this bug.