Bug 1008021 - Self entry access ACI not working properly
Self entry access ACI not working properly
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
6.5
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Rich Megginson
Sankar Ramalingam
: Reopened
Depends On: 951754
Blocks: 1061410
  Show dependency treegraph
 
Reported: 2013-09-13 15:49 EDT by Nathan Kinder
Modified: 2014-10-14 03:50 EDT (History)
6 users (show)

See Also:
Fixed In Version: 389-ds-base-1.2.11.15-34.el6
Doc Type: Bug Fix
Doc Text:
Cause: using self entry access aci, if an operation evaluates access on several entries (search returning several entries), the result of a granted access for an entry is cached and can erroneously be reused for all entries Consequence: A bound client can retrieve entries/attributes he should not be allowed or can fail to retrieve entries/attributes he should be allowed Fix: Some access are granted per entry, make sure that if granted access is cached it is purged for the next entry Result: A self access aci, should be evaluated evaluated for each entry
Story Points: ---
Clone Of: 951754
Environment:
Last Closed: 2014-10-14 03:50:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nathan Kinder 2013-09-13 15:49:17 EDT
+++ 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.
Comment 1 RHEL Product and Program Management 2014-03-16 15:36:26 EDT
Quality Engineering Management has reviewed and declined this request.
You may appeal this decision by reopening this request.
Comment 2 Nathan Kinder 2014-03-16 21:26:49 EDT
Reopening, as this is a bug that engineering wants to get in for RHEL 6.6.  Was the qe_ack- flag set by accident for this?
Comment 4 Viktor Ashirov 2014-06-26 13:04:59 EDT
$ ldapadd -D 'cn=Directory Manager' -w Secret123  -H ldap://localhost:1389 << EOF
> dn: cn=test1,dc=example,dc=com
> objectClass: inetorgperson
> objectClass: organizationalPerson
> objectClass: person
> objectClass: top
> uid: test
> sn: test1
> cn: test1
> userPassword: Secret12
> 
> dn: cn=test2,dc=example,dc=com
> objectClass: inetorgperson
> objectClass: organizationalPerson
> objectClass: person
> objectClass: top
> uid: test
> sn: test2
> cn: test2
> userPassword: Secret12
> EOF
adding new entry "cn=test1,dc=example,dc=com"

adding new entry "cn=test2,dc=example,dc=com"

$ ldapmodify -D 'cn=Directory Manager' -w Secret123  -H ldap://localhost:1389  << EOF
> dn: dc=example,dc=com
> changetype: modify
> delete: aci
> EOF
modifying entry "dc=example,dc=com"

$ ldapmodify -D 'cn=Directory Manager' -w Secret123  -H ldap://localhost:1389  << EOF
> dn: dc=example,dc=com
> changetype: modify
> add: aci
> aci: (targetattr="*")(version 3.0; acl "Allow self entry access"; allow (read,search,compare) userdn = "ldap:///self";)
> EOF
modifying entry "dc=example,dc=com"

$ ldapsearch -LLL -D 'cn=test1,dc=example,dc=com' -w Secret12 -b 'dc=example,dc=com' 'uid=test' -H ldap://localhost:1389
dn: cn=test1,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
uid: test
sn: test1
cn: test1
userPassword:: e1NTSEF9QWpjMnh3NHRPZmd5MVBpRDZjUWtyaFgvdjFGY2ZrbU41d1N3V1E9PQ=
 =

$ ldapsearch -LLL  -D 'cn=test2,dc=example,dc=com' -w Secret12 -b 'dc=example,dc=com' 'uid=test' -H ldap://localhost:1389
dn: cn=test2,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
uid: test
sn: test2
cn: test2
userPassword:: e1NTSEF9YXNscG9DMEtvZGozcmRKSnp2emNrYVFhVHFIdEhKMDM1VWgvckE9PQ=
 =

$ rpm -qa | grep 389
389-ds-base-debuginfo-1.2.11.15-36.el6.x86_64
389-ds-base-libs-1.2.11.15-36.el6.x86_64
389-ds-base-1.2.11.15-36.el6.x86_64
Comment 5 thierry bordaz 2014-06-27 09:57:24 EDT
Without the fix, the test case described above should have return:

ldapsearch -LLL -D 'cn=test1,dc=example,dc=com'...
dn: cn=test1,dc=example,dc=com
...

dn: cn=test2,dc=example,dc=com
...


And bound with cn=test2:

ldapsearch -LLL  -D 'cn=test2,dc=example,dc=com'...
<nothing>
Comment 6 errata-xmlrpc 2014-10-14 03:50:16 EDT
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.

http://rhn.redhat.com/errata/RHBA-2014-1385.html

Note You need to log in before you can comment on or make changes to this bug.