Red Hat Bugzilla – Bug 1135433
Dereference code errors out when dereferencing entries protected by ACIs
Last modified: 2015-03-05 05:33:29 EST
+++ This bug was initially created as a clone of Bug #1135432 +++ This bug is created as a clone of upstream ticket: https://fedorahosted.org/sssd/ticket/2421 The dereference code currently fails completely when processing initgroups of an IPA user who is a member of some Role or linked to a Permission against a new (4.0) IPA server. This is because in 4.0, IPA switched to a different permission model that no longer allows the host principal to read the rbac and pbac containers. The current dereference code errors out when it can't read even the objectclass of an entry. This bug could be also triggered outside IPA, just by restricting the ACI on the linked entry.
master: 2284e50c801a53541016eb9a5af00d1250d36afb 0321da68a393943797ea8cb9eb5e9672431ff8f4 sssd-1-11: ffe42e0158df6e4b2aad91e9a0cd75aff05be8c4
Please add stpes to verify
This will be difficult to verify with default installation given that DS side in Bug 1140888 was fixed. But I am thinking we may add a new test FreeIPA permission allowing reading entryusn (i.e. effectively revert https://fedorahosted.org/freeipa/ticket/4534) to all authenticated members in all entries to force DS return dereferenced entries without objectclass: 1) Install FreeIPA server 2) Install FreeIPA client 3) On server, add the permission: # ipa permission-add test --attrs entryusn --right read --bindtype all --subtree SUFFIX
How can we confirm this has succeeded? How/where would we see the dereference code fail processing initgroups? [root@vm8 ~]# kinit admin Password for admin@IPA2.EXAMPLE.COM: [root@vm8 ~]# ipa user-add testuser1 --first=f --last=l ---------------------- Added user "testuser1" ---------------------- User login: testuser1 First name: f Last name: l Full name: f l Display name: f l Initials: fl Home directory: /home/testuser1 GECOS: f l Login shell: /bin/sh Kerberos principal: testuser1@IPA2.EXAMPLE.COM Email address: testuser1@ipa2.example.com UID: 1370600003 GID: 1370600003 Password: False Member of groups: ipausers Kerberos keys available: False [root@vm8 ~]# ipa permission-add test --attrs entryusn --right read --bindtype all --subtree "dc=ipa2,dc=example,dc=com" ----------------------- Added permission "test" ----------------------- Permission name: test Granted rights: read Effective attributes: entryusn Bind rule type: all Subtree: dc=ipa2,dc=example,dc=com [root@vm8 ~]# ipa user-add testuser2 --first=f --last=l---------------------- Added user "testuser2" ---------------------- User login: testuser2 First name: f Last name: l Full name: f l Display name: f l Initials: fl Home directory: /home/testuser2 GECOS: f l Login shell: /bin/sh Kerberos principal: testuser2@IPA2.EXAMPLE.COM Email address: testuser2@ipa2.example.com UID: 1370600004 GID: 1370600004 Password: False Member of groups: ipausers Kerberos keys available: False On the client: [root@vm9 ~]# id testuser1 uid=1370600003(testuser1) gid=1370600003(testuser1) groups=1370600003(testuser1) [root@vm9 ~]# id testuser2 uid=1370600004(testuser2) gid=1370600004(testuser2) groups=1370600004(testuser2) Is there a log entry I can look for to confirm this?
If resolving admin user in SSSD succeeds even after applying my proposed reproduction in Comment 5, I am not aware of other reproduction steps. If this is the case (and Jakub also does not know any), I would verify as SanityOnly.
Just testing "id" for sanity is good enough. To make sure the dereference call is used and not the individual lookups, set ldap_deref_threshold=1 in the domain section or test with users who are members of 10 or more groups.
Verified. Version :: Results :: See comment #6 above for first part. Next part, I added 2 users (testuser3 and testuser4) to 20 groups (testgroup1..20) on the IPA Server. Then on the client check with id command: [root@vm9 ~]# kdestroy -A [root@vm9 ~]# service sssd stop; rm -rf /var/lib/sss/{db,mc}/*; service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@vm9 ~]# id testuser3 uid=1370600025(testuser3) gid=1370600025(testuser3) groups=1370600025(testuser3),1370600008(testgroup4),1370600012(testgroup8),1370600015(testgroup11),1370600019(testgroup15),1370600023(testgroup19),1370600007(testgroup3),1370600011(testgroup7),1370600016(testgroup12),1370600020(testgroup16),1370600006(testgroup2),1370600010(testgroup6),1370600017(testgroup13),1370600021(testgroup17),1370600024(testgroup20),1370600005(testgroup1),1370600009(testgroup5),1370600013(testgroup9),1370600014(testgroup10),1370600018(testgroup14),1370600022(testgroup18) [root@vm9 ~]# id testuser4 uid=1370600026(testuser4) gid=1370600026(testuser4) groups=1370600026(testuser4),1370600024(testgroup20),1370600017(testgroup13),1370600009(testgroup5),1370600022(testgroup18),1370600015(testgroup11),1370600020(testgroup16),1370600006(testgroup2),1370600005(testgroup1),1370600011(testgroup7),1370600010(testgroup6),1370600018(testgroup14),1370600023(testgroup19),1370600016(testgroup12),1370600007(testgroup3),1370600012(testgroup8),1370600021(testgroup17),1370600014(testgroup10),1370600019(testgroup15),1370600008(testgroup4),1370600013(testgroup9) And then just to make sure, I also added ldap_deref_threshold=1 in the domain section and reran the id check: [root@vm9 ~]# vi /etc/sssd/sssd.conf [root@vm9 ~]# service sssd stop; rm -rf /var/lib/sss/{db,mc}/*; service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@vm9 ~]# id testuser3 uid=1370600025(testuser3) gid=1370600025(testuser3) groups=1370600025(testuser3),1370600008(testgroup4),1370600012(testgroup8),1370600015(testgroup11),1370600019(testgroup15),1370600023(testgroup19),1370600007(testgroup3),1370600011(testgroup7),1370600016(testgroup12),1370600020(testgroup16),1370600006(testgroup2),1370600010(testgroup6),1370600017(testgroup13),1370600021(testgroup17),1370600024(testgroup20),1370600005(testgroup1),1370600009(testgroup5),1370600013(testgroup9),1370600014(testgroup10),1370600018(testgroup14),1370600022(testgroup18) [root@vm9 ~]# id testuser4 uid=1370600026(testuser4) gid=1370600026(testuser4) groups=1370600026(testuser4),1370600024(testgroup20),1370600017(testgroup13),1370600009(testgroup5),1370600022(testgroup18),1370600015(testgroup11),1370600020(testgroup16),1370600006(testgroup2),1370600005(testgroup1),1370600011(testgroup7),1370600010(testgroup6),1370600018(testgroup14),1370600023(testgroup19),1370600016(testgroup12),1370600007(testgroup3),1370600012(testgroup8),1370600021(testgroup17),1370600014(testgroup10),1370600019(testgroup15),1370600008(testgroup4),1370600013(testgroup9)
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. https://rhn.redhat.com/errata/RHBA-2015-0441.html