On 01/13/2014 03:27 PM, 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)?
yes. Create a ticket and add the full aci and the log messages. I agree that it should not be a fatal message.

On to my case. I'm getting messages like this in my errors log (Centos 6.5, 
389DS 1.2.11.15):
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
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/389-users

Reply via email to