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 951754 - Self entry access ACI not working properly
Summary: Self entry access ACI not working properly
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.1
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: 7.1
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 1008021
TreeView+ depends on / blocked
 
Reported: 2013-04-13 01:46 UTC by Thang Nguyen
Modified: 2020-09-13 20:28 UTC (History)
4 users (show)

Fixed In Version: 389-ds-base-1.3.3.1-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1008021 (view as bug list)
Environment:
Last Closed: 2015-03-05 09:30:28 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 668 0 None None None 2020-09-13 20:28:29 UTC
Red Hat Product Errata RHSA-2015:0416 0 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description Thang Nguyen 2013-04-13 01:46:27 UTC 
Description of problem:
I've two records in 389ds with the same uid value.  

For example:

dn: uid=user1,ou=unix_users,dc=localdomain
uid: user1
cn: user1 name
objectclass: top
objectclass: person

dn: cn=user1 name,ou=people,dc=localdomain
uid: thang
cn: user1 name
objectclass: top
objectclass: person

I added "dn: uid=user1,ou=unix_user,dc=localdomain" first and then added "dn: cn=test user1,ou=people,dc=localdomain" (the order is important).

I've an ACI to allow read, compare and search from ldap:///self:

aci: (targetattr="*")(version 3.0; acl "Allow self entry access"; allow (read,search,compare) userdn = "ldap:///self";)


When I do a ldapsearch as following:

ldapsearch -D 'cn=user1 name,ou=people,dc=localdomain' -w password -b 'ou=people,dc=localdomain' 'uid=user1'

The ldapsearch doesn't return anything.

The error log shows:
12/Apr/2013:12:21:12 -1000] NSACLPlugin - acl_init_userGroup: found in cache for dn:cn=user1 name,ou=people,dc=localdomain
[12/Apr/2013:12:21:12 -1000] NSACLPlugin - Failed to find root for base: dc=edu
[12/Apr/2013:12:21:12 -1000] NSACLPlugin - #### conn=46 op=3 binddn="cn=user1 name,ou=people,dc=localdomain"
[12/Apr/2013:12:21:12 -1000] NSACLPlugin - Searching AVL tree for update:uid=user1,ou=unix_users,dc=localdomain: container:-1
[12/Apr/2013:12:21:12 -1000] NSACLPlugin - Searching AVL tree for update:ou=unix_users,dc=localdomain: container:-1
[12/Apr/2013:12:21:12 -1000] NSACLPlugin -     ************ RESOURCE INFO STARTS *********
[12/Apr/2013:12:21:12 -1000] NSACLPlugin -     Client DN: cn=user1 name,ou=people,dc=localdomain
[12/Apr/2013:12:21:12 -1000] NSACLPlugin -     resource type:768(search target_DN target_attr )
[12/Apr/2013:12:21:12 -1000] NSACLPlugin -     Slapi_Entry DN: uid=user1,ou=unix_users,dc=localdomain
[12/Apr/2013:12:21:12 -1000] NSACLPlugin -     ATTR: uid
[12/Apr/2013:12:21:12 -1000] NSACLPlugin -     rights:search
[12/Apr/2013:12:21:12 -1000] NSACLPlugin -     ************ RESOURCE INFO ENDS   *********
[12/Apr/2013:12:21:12 -1000] NSACLPlugin - conn=46 op=3 (main): Deny search on entry(uid=user1,ou=unix_users,dc=localdomain).attr(uid) to cn=user1 name,ou=people,dc=localdomain: no aci matched the subject by aci(182): aciname= "Allow self entry access", acidn="dc=localdomain"

The interesting thing is that the client DN is "cn=user1 name,ou=people,dc=localdomain" and the Slapi_Entry DN is "uid=user1,ou=unix_users,dc=localdomain.

However I get the "uid=user1,ou=unix_users,dc=localdomain" record 
when I do
ldapsearch -D 'uid=user1,ou=unix_users,dc=localdomain' -w password -b 'ou=unix_users,dc=localdomain' 'uid=user1'

I'm thinking the "uid=user1" is cached under "uid=user1,ou=unix_users,dc=localdomain" and not under "cn=user1 name,ou=people,dc=localdomain".

After I deleted "uid=user1,ou=unix_users,dc=localdomain", I'm able to do a self search with 

ldapsearch -D 'cn=user1 name,ou=people,dc=localdomain' -w password -b 'ou=people,dc=localdomain' 'uid=user1'


After I added back "uid=user1,ou=unix_users,dc=localdomain", I was able to do a self search

ldapsearch -D 'cn=user1 name,ou=people,dc=localdomain' -w password -b 'ou=people,dc=localdomain' 'uid=user1'

but NOT

ldapsearch -D 'uid=user1,ou=unix_users,dc=localdomain' -w password -b 'ou=people,dc=localdomain' 'uid=user1'

So I think whatever attributes were added first, it will be cached under that dn.  

Can you please check if this is a bug and any fix or workaround?  thanks.

Regards,

--thang
Comment 1 Nathan Kinder 2013-04-13 04:37:50 UTC 
In your example, you are searching for "uid=user1" under "ou=people,dc=localdomain", but no such entry exists.  The entry beneath "ou=people,dc=localdomain" has "uid=thang", so your search filter will never match that entry.

The ACI debugging shows that you are properly denied "search" access to "uid=user1,ou=unix_users,dc=localdomain" since you are bound as a different user.
Comment 2 Thang Nguyen 2013-04-13 05:52:50 UTC 
Hi Nathan,

Sorry... I had a typo.  The uid on both record has the same value, "uid=user1".

You can reproduce by creating two records in separate OU with the same value for "uid".  Then create the aci

aci: (targetattr="*")(version 3.0; acl "Allow self entry access"; allow (read,search,compare) userdn = "ldap:///self";)

Then you can do a self search for the "uid=<value>" from both DNs you just added.  When you bind as the first DN you added, you will get a back the record.  If you bind as the second DN you added, you will not get back anything.  

Thanks for looking into this.

Regards,

--thang
Comment 3 Nathan Kinder 2013-04-16 15:57:09 UTC 
Upstream ticket:
https://fedorahosted.org/389/ticket/47331
Comment 4 Thang Nguyen 2013-09-13 19:24:42 UTC 
Hi Nathan,

Is it possible that you put this fix in the 389-ds-base package on Red Hat Enterprise Linux 6?
Comment 5 Nathan Kinder 2013-09-13 19:48:28 UTC 
(In reply to Thang Nguyen from comment #4)
> Hi Nathan,
> 
> Is it possible that you put this fix in the 389-ds-base package on Red Hat
> Enterprise Linux 6?

This is not currently targeted for inclusion in RHEL6.  We can certainly consider it for a future RHEL 6 update.
Comment 6 Thang Nguyen 2013-09-13 19:56:26 UTC 
Thanks Nathan.  Please highly consider adding this fix to the new release of 389-ds-base package in RHEL 6.  This feature is very important in our environment.  Can you please let me know the ETA to have this available in RHEL 6?  I just want to let our users who affected by this bug know.  Thank you.

Regards,

--thang
Comment 7 Nathan Kinder 2013-09-13 20:03:26 UTC 
(In reply to Thang Nguyen from comment #6)
> Thanks Nathan.  Please highly consider adding this fix to the new release of
> 389-ds-base package in RHEL 6.  This feature is very important in our
> environment.  Can you please let me know the ETA to have this available in
> RHEL 6?  I just want to let our users who affected by this bug know.  Thank
> you.
> 
> Regards,
> 
> --thang

I don't have an exact ETA, but it would still be quite a ways out.  If you want this to be prioritized, you should open up a Red Hat support ticket against Red Hat Directory Server (if you have a support contract).

For continued discussion about fixing this in RHEL6, please update the RHEL6 specific cloned bug I made for this issue (bug 1008021).
Comment 8 Thang Nguyen 2013-09-13 20:25:01 UTC 
Thanks Nathan.
Comment 10 Sankar Ramalingam 2014-11-25 18:34:46 UTC 
Self entry ACI is working fine. Every user is able to see their own information. 
I followed these steps to verify bugzilla.

Added a suffix with self entry search aci.
aci: (targetattr="*")(version 3.0; acl "Allow self entry access"; allow (read,search,compare) userdn = "ldap:///self";)

Added 4 users:
dn: uid=newaciusr1,ou=People,dc=testaci,dc=com
dn: uid=testaciusr1,ou=Groups,dc=testaci,dc=com
dn: uid=testaciusr1,ou=People,dc=testaci,dc=com
dn: uid=testaciusr1,ou=Public,dc=testaci,dc=com

[root@vm-idm-042 MMR_WINSYNC]# ldapsearch -x -p 1989 -h localhost -D "uid=testaciusr1,ou=public,dc=testaci,dc=com" -w Secret123 -b "dc=testaci,dc=com"
dn: uid=testaciusr1,ou=Public,dc=testaci,dc=com
telephoneNumber: 989898191
mail: testaciusr1
uid: testaciusr1
givenName: testaciusr1
objectClass: top


[root@vm-idm-042 MMR_WINSYNC]# ldapsearch -x -p 1989 -h localhost -D "uid=newaciusr1,ou=people,dc=testaci,dc=com" -w Secret123 -b "ou=people,dc=testaci,dc=com"
dn: uid=newaciusr1,ou=People,dc=testaci,dc=com
telephoneNumber: 989898191
mail: newaciusr1
uid: newaciusr1
givenName: newaciusr1

[root@vm-idm-042 MMR_WINSYNC]# ldapsearch -x -p 1989 -h localhost -D "uid=testaciusr1,ou=groups,dc=testaci,dc=com" -w Secret123 -b "dc=testaci,dc=com"
dn: uid=testaciusr1,ou=Groups,dc=testaci,dc=com
telephoneNumber: 989898191
mail: testaciusr1
uid: testaciusr1
givenName: testaciusr1
objectClass: top
objectClass: person


marking the bug as verified based on the search results.
Comment 12 Rich Megginson 2014-11-25 21:31:51 UTC 
Thierry and Noriko both worked on this bug.
Comment 14 Sankar Ramalingam 2014-12-03 12:09:37 UTC 
Thanks for your answer. Its perfect.
Comment 16 errata-xmlrpc 2015-03-05 09:30:28 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/RHSA-2015-0416.html
Note You need to log in before you can comment on or make changes to this bug.