On 01/13/2014 07:27 AM, Chris Chatfield wrote:
Hi,
I'm seeing a similar situation as was described in the mailing list message
"errors log - NSACLPlugin - acllas__client_match_URL:" from Feb 2013. The final
result of this was a suggestion to file a ticket. As far as I can see this wasn't
done. Should I do this (for my scenario)?
On to my case. I'm getting messages like this in my errors log (Centos 6.5, 389DS
1.2.11.15):
What is the exact version? rpm -q 389-ds-base
NSACLPlugin - acllas__client_match_URL: url
[ldap:///gcUID=0001ab51,o=Teamphone.com??sub?(objectclass=gcsubscriber)] scope is subtree
but dn [
gcUID=0001ab51,o=Teamphone.com] is not a suffix of [cn=tp
manager,ou=configuration,o=teamphone.com]
There are acis at the
o=teamphone.com subtree which allow administrators access to the
whole tree.
There are acis at the
gcUID=0001ab51,o=Teamphone.com subtree which allow gcsubscriber
entries within that tree to have limited access to the subtree. Note that we have extended
the schema such that gcsubscribers extend person, amongst other things. I do not believe
this makes any difference to the problem.
The message happens on a connection bound to cn=tp
manager,ou=configuration,o=teamphone.com (an administrator) when it searches within the
subtree
gcUID=0001ab51,o=Teamphone.com. It seems the acis at
gcUID=0001ab51,o=Teamphone.com are being evaluated in the context of this administrator.
In this case the administrator does not match the aci's userdn url path. This is
deliberate as this aci is concerned with gcsubscriber access, not admin access. Other acis
higher up give the correct admin access.
So in summary, I think 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). I notice that the git comment suggested that these lines were debugging.
Would that be the right approach? We're moving away from the Sun/Oracle 5.2 directory
server, and this aci is behaving quietly there.
Many thanks,
Chris
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users