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 1135433 - Dereference code errors out when dereferencing entries protected by ACIs
Summary: Dereference code errors out when dereferencing entries protected by ACIs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.1
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On: 1135432
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-29 09:56 UTC by Jakub Hrozek
Modified: 2020-05-04 10:41 UTC (History)
10 users (show)

Fixed In Version: sssd-1.12.1-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 1135432
Environment:
Last Closed: 2015-03-05 10:33:29 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 3463 0 None None None 2020-05-04 10:41:53 UTC
Red Hat Product Errata RHBA-2015:0441 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2015-03-05 15:05:27 UTC

Description Jakub Hrozek 2014-08-29 09:56:44 UTC 
+++ 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.
Comment 2 Jakub Hrozek 2014-09-09 08:41:36 UTC 
master:
    2284e50c801a53541016eb9a5af00d1250d36afb
    0321da68a393943797ea8cb9eb5e9672431ff8f4 
sssd-1-11:
    ffe42e0158df6e4b2aad91e9a0cd75aff05be8c4
Comment 3 Namita Soman 2014-09-09 12:02:53 UTC 
Please add stpes to verify
Comment 5 Martin Kosek 2014-09-22 11:11:03 UTC 
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
Comment 6 Scott Poore 2015-01-28 04:22:09 UTC 
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.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.COM
  Email address: testuser1.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.COM
  Email address: testuser2.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?
Comment 7 Martin Kosek 2015-01-28 09:12:21 UTC 
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.
Comment 8 Jakub Hrozek 2015-01-28 10:50:26 UTC 
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.
Comment 9 Scott Poore 2015-01-28 15:23:16 UTC 
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)
Comment 11 errata-xmlrpc 2015-03-05 10:33:29 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.

https://rhn.redhat.com/errata/RHBA-2015-0441.html
Note You need to log in before you can comment on or make changes to this bug.