Bug 951754

Summary:	Self entry access ACI not working properly
Product:	Red Hat Enterprise Linux 7	Reporter:	Thang Nguyen <thang>
Component:	389-ds-base	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED ERRATA	QA Contact:	Viktor Ashirov <vashirov>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.1	CC:	nhosoi, nkinder, rmeggins, tbordaz
Target Milestone:	rc
Target Release:	7.1
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	389-ds-base-1.3.3.1-1.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1008021 (view as bug list)		Environment:
Last Closed:	2015-03-05 09:30:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1008021

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