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 1008021 - 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 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.5
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Sankar Ramalingam
URL:
Whiteboard:
Depends On: 951754
Blocks: 1061410
TreeView+ depends on / blocked
 
Reported: 2013-09-13 19:49 UTC by Nathan Kinder
Modified: 2020-09-13 20:28 UTC (History)
6 users (show)

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
Clone Of: 951754
Environment:
Last Closed: 2014-10-14 07:50:16 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 closed Self entry access ACI not working properly 2021-02-15 09:02:13 UTC
Red Hat Product Errata RHBA-2014:1385 0 normal SHIPPED_LIVE 389-ds-base bug fix and enhancement update 2014-10-14 01:27:42 UTC

Description Nathan Kinder 2013-09-13 19:49:17 UTC 
+++ 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 Program Management 2014-03-16 19:36:26 UTC 
Quality Engineering Management has reviewed and declined this request.
You may appeal this decision by reopening this request.
Comment 2 Nathan Kinder 2014-03-17 01:26:49 UTC 
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 17:04:59 UTC 
$ 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 13:57:24 UTC 
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 07:50:16 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.

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.