Red Hat Bugzilla – Bug 683885
SSSD should skip over groups with multiple names
Last modified: 2015-01-04 18:47:04 EST
Description of problem: The LDAP RFC2307 schema, while not explicitly allowing it, does not forbid the use of a multi-valued attribute for the name of a group. For example, if the group-name attribute is 'cn', it is permissible (though strongly advised against) to have two 'cn' values: 'groupname' and 'groupalias'. Right now, SSSD throws an error and aborts an initgroups call if it hits a group like this. We need to ensure that it logs a warning and skips the group. A future enhancement planned upstream will eventually add better support for these aliases. Version-Release number of selected component (if applicable): sssd-1.5.1-14.el6 How reproducible: Every time Steps to Reproduce: 1. Create a group in LDAP with two 'cn' values (e.g. 'groupname' and 'groupalias') 2. Add a user as a member of this group 3. Perform an initgroups call (e.g. 'id -G username') Actual results: The initgroups call returns only the user's primary GID Expected results: The initgroups call should return all groups that have only a single name. Additional info:
Many apologies. This bug did not get updated as we went through several revisions of how to resolve this issue. SSSD should now behave as follows: If we request a user or group that has alternate names, we will return the primary name (not necessarily the requested name) if it is possible to identify. This means that if one of the multiple names matches the RDN of the entry, that is the value that we will return. This will mean that 'getent group groupwithaliases' and 'getent group groupwithaliasesALIAS' will both return group information of the form: groupwithalias:::member1,member2 It will never return groupwithaliasesALIAS.
Sorry, I need to amend my previous statement. I was incorrect that we would return the primary group when requesting the secondary group. That did not make it into the final version of the patch. So the behavior as it is currently implemented will only return results for a lookup on the primary name.
setup: # user001, People, example.com dn: uid=user001,ou=People,dc=example,dc=com uidNumber: 29292 gidNumber: 29292 objectClass: top objectClass: posixAccount objectClass: inetuser cn: user001 homeDirectory: /home/user001 loginShell: /bin/bash uid: user001 # group001, Groups, example.com dn: cn=group001,ou=Groups,dc=example,dc=com gidNumber: 29292 objectClass: top objectClass: posixGroup cn: group001alias cn: group001 memberUid: user001 # group002, Groups, example.com dn: cn=group002,ou=Groups,dc=example,dc=com gidNumber: 29293 objectClass: top objectClass: posixGroup cn: group002alias cn: group002 memberUid: user001 Client: # id -G -n user001 group001 group002 group003 group 004 # getent group group002 group002:*:29293:user001 # getent group group002alias # No results returned while requesting for groupaliasALIAS as expected. # rpm -qi sssd | head Name : sssd Relocations: (not relocatable) Version : 1.5.1 Vendor: Red Hat, Inc. Release : 24.el6 Build Date: Sat 02 Apr 2011 01:24:54 AM IST Install Date: Tue 05 Apr 2011 11:11:29 AM IST Build Host: x86-012.build.bos.redhat.com Group : Applications/System Source RPM: sssd-1.5.1-24.el6.src.rpm Size : 3462740 License: GPLv3+ Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://fedorahosted.org/sssd/ Summary : System Security Services Daemon
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0560.html