[Date Prev][Date Next]
Re: access control 'set=' problem (ITS#3140)
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 ?
> 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/