Red Hat Bugzilla – Bug 951754
Self entry access ACI not working properly
Last modified: 2015-03-05 04:30:28 EST
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
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.
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
Upstream ticket: https://fedorahosted.org/389/ticket/47331
Hi Nathan, Is it possible that you put this fix in the 389-ds-base package on Red Hat Enterprise Linux 6?
(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.
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
(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).
Thanks Nathan.
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@redhat.com 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@redhat.com 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@redhat.com uid: testaciusr1 givenName: testaciusr1 objectClass: top objectClass: person marking the bug as verified based on the search results.
Thierry and Noriko both worked on this bug.
Thanks for your answer. Its perfect.
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