Bug 733399 - Unable to enumerate rfc2307bis group with non-default attribute names.
Summary: Unable to enumerate rfc2307bis group with non-default attribute names.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Stephen Gallagher
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 748874
TreeView+ depends on / blocked
 
Reported: 2011-08-25 16:00 UTC by Kaushik Banerjee
Modified: 2015-01-04 23:50 UTC (History)
6 users (show)

Fixed In Version: sssd-1.5.1-49.el6
Doc Type: Bug Fix
Doc Text:
Cause: SSSD uses internal cache to store all entities retrieved from server. Attributes of these entities can have different name in the cache and remote server. In couple cases, SSSD used attribute names for the remote server instead of names for local cache. Consequence: When non-default attribute names were used either for group GID or name, all groups were processed and stored to the cache incorrectly, thus not returned to NSS client. Fix: Cache attribute names are now correctly used when processing groups retrieved from server. Result: Groups retrieved from servers with non-standard attribute names are stored and returned correctly.
Clone Of:
: 748874 (view as bug list)
Environment:
Last Closed: 2011-12-06 16:39:40 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1529 normal SHIPPED_LIVE sssd bug fix and enhancement update 2011-12-06 00:50:20 UTC
FedoraHosted SSSD 983 None None None Never

Description Kaushik Banerjee 2011-08-25 16:00:22 UTC
Description of problem:
Unable to enumerate rfc2307bis group with non-default attribute names.

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

How reproducible:
Always

Steps to Reproduce:
1. Setup a ldap schema with non-default attribute names and add a user using those attribute names:
Add a user-group with the following attributes:

dn: uid=kau12,dc=example,dc=com
objectClass: account
objectClass: posixAccount1
cn1: kaushik12
uid1: kau12
uidNumber1: 121212
gidNumber1: 121212
homeDirectory1: /home/kau12
loginShell1: /bin/tcsh
gecos1: GECOS TEST
userPassword: XXXXX

dn: cn=kau12_grp1,dc=example,dc=com
gidNumber1: 121212
objectClass: extensibleObject
objectClass: groupOfNames1
member1: uid=kau12,dc=example,dc=com
cn1: kau12_grp1

2. Setup sssd with the following in domain section:
[domain/LDAP]
debug_level=9
id_provider = ldap
ldap_tls_cacert=/etc/openldap/cacerts/server.pem
ldap_uri = ldap://<ldap-server>
ldap_search_base = dc=example,dc=com
ldap_user_object_class = posixAccount1
ldap_user_name = uid1
ldap_user_uid_number = uidNumber1
ldap_user_gid_number = gidNumber1
ldap_user_gecos = gecos1
ldap_user_home_directory = homeDirectory1
ldap_user_shell = loginShell1
ldap_group_gid_number = gidNumber1
ldap_user_fullname = cn1
ldap_group_name = cn1
ldap_schema = rfc2307bis
ldap_group_object_class = groupOfNames1
ldap_group_member = member1

3. Enumerate the user:
# id kau12
uid=121212(kau12) gid=121212 groups=121212

4. Enumerate the group
# getent -s sss group kau12_grp1
#

Actual results:
Unable to enumerate group

/var/log/sssd/sssd_LDAP.log shows:

<snip>
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (6): calling ldap_search_ext with [(&(cn1=kau12_grp1)(objectclass=groupOfNames1)(cn1=*)(&(gidNumber1=*)(!(gidNumber1=0))))][dc=example,dc=com].
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [objectClass]
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [cn1]
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [userPassword]
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [gidNumber1]
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [member1]
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [nsUniqueId]
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [modifyTimestamp]
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (8): ldap_search_ext called, msgid = 3
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_id_op_connect_done] (9): caching successful connection after 1 notifies
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x81432a8], connected[1], ops[0x814cb58], ldap[0x81433b0]
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: ldap_result found nothing!
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x81432a8], connected[1], ops[0x814cb58], ldap[0x81433b0]
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_parse_entry] (9): OriginalDN: [cn=kau12_grp1,dc=example,dc=com].
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x81432a8], connected[1], ops[0x814cb58], ldap[0x81433b0]
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Success(0), (null)
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_done] (7): Total count [0]
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_groups_process] (6): Search for groups, returned 1 results.
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_nested_group_process_send] (9): The group's gid was missing
(Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_nested_group_process_send] (8): Marking group as non-posix and setting GID=0!
</snip>

Expected results:
Enumeration of the group should work.

Additional info:

Comment 2 Stephen Gallagher 2011-08-26 12:58:28 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/983

Comment 3 Jakub Hrozek 2011-08-28 06:49:05 UTC
Kaushik, is this the issue that was solved by the scratch build I gave you? If so, then it is already fixed upstream (#975).

Comment 4 Kaushik Banerjee 2011-08-29 06:39:39 UTC
(In reply to comment #3)
> Kaushik, is this the issue that was solved by the scratch build I gave you? If
> so, then it is already fixed upstream (#975).

Yes. The issue was solved with the scratch build. The bug was logged to track the issue on rhel6.2 build.

Comment 8 Kaushik Banerjee 2011-09-15 16:46:59 UTC
Verified in version:

# rpm -qi sssd | head
Name        : sssd                         Relocations: (not relocatable)
Version     : 1.5.1                             Vendor: Red Hat, Inc.
Release     : 51.el6                        Build Date: Mon 12 Sep 2011 06:55:14 PM IST
Install Date: Tue 13 Sep 2011 08:02:21 PM IST      Build Host: x86-001.build.bos.redhat.com
Group       : Applications/System           Source RPM: sssd-1.5.1-51.el6.src.rpm
Size        : 3670464                          License: GPLv3+
Signature   : (none)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://fedorahosted.org/sssd/
Summary     : System Security Services Daemon

Comment 9 Jan Zeleny 2011-10-27 13:59:29 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: SSSD uses internal cache to store all entities retrieved from server. Attributes of these entities can have different name in the cache and remote server. In couple cases, SSSD used attribute names for the remote server instead of names for local cache.
Consequence: When non-default attribute names were used either for group GID or name, all groups were processed and stored to the cache incorrectly, thus not returned to NSS client.
Fix: Cache attribute names are now correctly used when processing groups retrieved from server.
Result: Groups retrieved from servers with non-standard attribute names are stored and returned correctly.

Comment 10 errata-xmlrpc 2011-12-06 16:39:40 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.