[Date Prev][Date Next]
Re: access control 'set=' problem (ITS#3140)
I think I got it: the function that evaluates if a set matches
calls aci_match_set(), which on turn calls backend_attribute()
to access the specific attribute that's used by the set in a
backend-independent manner. This function has been recently
reworked to only access those attributes that can be actually
accessed by the requester, i.e. it assesses access permission
as well, causing the andless recursion I mentioned earlier.
I think a solution would be to specialize backend_attribute to
skip ACL check on certain calls. I'll have a look at it.
> This problem is not platform or back-end dependant, I agree with you.
> However, I do not see the endless loop you are talking about : as I
> understand it, the set clause access control
> access to *
> by set="[cn=admins,o=myorg,c=fr]/member* & user" write
> by * read
> builds a set which contains all the DNs in the member attribute of
> "cn=admins,o=myorg,c=fr", and proceeds recursively until the DNs in the
> member attribute do not have a member attribute. I do not see any
> relation with the DN that access is currently checked for ; or the crash
> depends on that. This may loop if a group contains a second group which
> contains the first group (or with more intermediate groups), but this is
> not the case. Moreover, this access control worked fine with openldap
> 2.0.x and 2.1.x.
> Maybe the signification of the set has changed with openldap 2.2.x,
> because when I set loglevel to -1 and perform a tail -f on the log file,
> I do see the output of the ldapsearch stopping while the log file keeps
> increasing for a few seconds before the server crashes.
> By the way, is there another way of performing such a recursive check
> without using sets ?
> Best regards,
> Selon firstname.lastname@example.org:
>> The problem can be easily reproduced even with a very simple set of
>> test data, e.g. those coming along with OpenLDAP software. The crash
>> is not related to a specific bug, but to set ACL check running in an
>> endless loop that exausts resources. Sets code needs to be reviewed;
>> also, I'm unable to understand if the way you used it is correct (but
>> it should not end up in an unrecoverable situation, though).
> This mail sent through IMP: http://horde.org/imp/
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497