#47670 ACI warnings in error log
Closed: wontfix None Opened 8 years ago by chatfield.

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

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.

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

5 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

2 years ago

Login to comment on this ticket.

Metadata