[Date Prev][Date Next] [Chronological] [Thread] [Top]

ACL caching is broken (ITS#2679)



Full_Name: Ralf Haferkamp
Version: HEAD, > 2.1.12
OS: Linux
URL: 
Submission from: (NULL) (212.95.104.244)


example setup:

dn: dc=home,dc=local
objectClass: dcObject
objectClass: organization
dc: home
o: test
o: test1

with only the folling ACL:

access to dn.base="dc=home,dc=local" attr=objectclass,entry,dc
    by * read

ldapsearch -x -b dc=home,dc=local -s base

Will not return the attribute "dc". Here is an excerpt of the log with -d 128:

=> access_allowed: read access to "dc=home,dc=local" "o" requested
=> dn: [1] dc=home,dc=local
=> acl_get: [1] matched
=> acl_get: [1] check attr o
<= acl_get: done.
=> access_allowed: no more rules
acl: access to attribute o not allowed
=> access_allowed: read access to "dc=home,dc=local" "dc" requested
=> dn: [1] dc=home,dc=local
=> acl_get: [1] matched
=> acl_get: [1] check attr dc
<= acl_get: [1] acl dc=home,dc=local attr: dc
access_allowed: result from state (dc)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
acl: access to attribute dc not allowed

My guess it is that the following code isn't quite correct (acl.c line 305):
if (state) {
    if (state->as_vi_acl == a && (state->as_recorded & ACL_STATE_RECORDED_NV))
{
        Debug( LDAP_DEBUG_ACL, "access_allowed: result from state (%s)\n", attr,
0, 0 );
        ret = state->as_result;
        goto done;
    } else if (!st_initialized) {
    [..]

It uses the state from the previous access_allowed call, which was for "o". And
just returns its results. I think this should only be done when there is no
"attr=..." in the to-clause of the ACL. So a additional "a->acl_attr == NULL"
might fix it. Right?