Bug 1008021

+++ This bug was initially created as a clone of Bug #951754 +++

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

--- Additional comment from Nathan Kinder on 2013-04-13 00:37:50 EDT ---

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.

--- Additional comment from Thang Nguyen on 2013-04-13 01:52:50 EDT ---

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

--- Additional comment from Nathan Kinder on 2013-04-16 11:57:09 EDT ---

Upstream ticket:
https://fedorahosted.org/389/ticket/47331

--- Additional comment from Thang Nguyen on 2013-09-13 15:24:42 EDT ---

Hi Nathan,

Is it possible that you put this fix in the 389-ds-base package on Red Hat Enterprise Linux 6?

--- Additional comment from Nathan Kinder on 2013-09-13 15:48:28 EDT ---

(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.