Hide Forgot
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.
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.
Upstream ticket: https://fedorahosted.org/sssd/ticket/1013
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
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.
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.
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