I have an admin user in one part of the subtree, and users within a department in a separate subtree. There is an aci at the top of the tree that gives the admin user complete access to everything. There is an aci that gives departmental users visibility of each other.
The ldif of this example tree is attached.
When a search is performed by one of the departmental users, the result is correct and the errors log is quiet. ldapsearch -D "uid=uone,ou=users,ou=london office,o=resilient.com" -w password -b "ou=London Office,o=resilient.com" "cn=User Two"
When a search is performed by the admin user, the result is correct, but the errors log has extra lines added. ldapsearch -D "uid=fsmith,ou=admins,o=resilient.com" -w password -b "ou=London Office,o=resilient.com" "cn=User Two" [13/Jan/2014:16:02:54 +0000] NSACLPlugin - acllas__client_match_URL: url [ldap:///ou=London Office,o=resilient.com??sub?(objectclass=person)] scope is subtree but dn [ou=London Office,o=resilient.com] is not a suffix of [uid=fsmith,ou=admins,o=resilient.com]
The aci in question is: (target="ldap:///ou=London Office,o=resilient.com") (targetfilter="(objectclass=person)") (targetattr="cn")(version 3.0; acl "User Sees Colleagues"; allow (search, read, compare) userdn = "ldap:///ou=London Office,o=resilient.com??sub?(objectclass=person)";)
This is on version 389-ds-base-1.2.11.15-30.el6_5.x86_64 on Centos 6.5.
I believe this logging should be downgraded from SLAPI_LOG_FATAL to SLAPI_LOG_ACL for the "acllas__client_match_URL: url [%s] scope is subtree but dn [%s] is not a suffix of [%s]\n" message (and I guess similarly for the onelevel/base scopes too).
The complete tree for the example backup.ldif
Our local patch that solves the request 0114-Resilient-ACI-logging.patch
I got a notification that this case had been updated (comment 4), and this is why I uploaded our fix (attachment 2). I don't have a Red Hat account to see the case https://bugzilla.redhat.com/show_bug.cgi?id=1086454 so I don't know whether the patch is helpful. Anyway if the patch looks useful in general, it'd be good for it (or a version of it) to be applied to the git repository. Thanks.
Replying to [comment:5 chatfield]:
I got a notification that this case had been updated (comment 4), and this is why I uploaded our fix (attachment 2). I don't have a Red Hat account to see the case https://bugzilla.redhat.com/show_bug.cgi?id=1086454 so I don't know whether the patch is helpful.
I see in Bugzilla that there is a customer ticket associated with the bz. If you are the customer, ask your support person to add you to the Bugzilla so that you can see it.
Anyway if the patch looks useful in general, it'd be good for it (or a version of it) to be applied to the git repository. Thanks.
Once a 389 dev gets a chance to work on this issue, the dev will either push it as-is, or fix and push.
attachment 0001-Ticket-47670-Aci-warnings-in-error-log.patch
Replying to [comment:9 nhosoi]:
Noriko,
Do we still want to keep the milestone set to 1.3.3? Since there is a customer bug behind this should we push it to 1.2.11 and up?
Thanks, Mark
master
commit 4f14e7d Author: Mark Reynolds mreynolds@redhat.com Date: Wed May 21 14:36:01 2014 -0400
9c48a3a..c48c2d5 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit c48c2d5
04ecdb0..d8b7eb8 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit d8b7eb81ea6136f423f043df7b3e9fb6b333f5cd
a6c24c5..7fbf16b 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit 7fbf16b
Metadata Update from @chatfield: - Issue assigned to mreynolds - Issue set to the milestone: 1.2.11.30
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1007
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.