Hi,
we’re trying to (re-)implement some rather complicated ACLs, and are running into performance troubles.
Thing is, the ACLs are only (or at least mostly) complicated in the “I want to update stuff” case; read access is relatively straightforward.
For example, we have some group entries with lots of members, and want any authenticated user to be allowed to read those - but to update a group, you’ll have to both be in the “write allowed set" for the group and for the entries of the member DNs you’re touching.
You’re in the “write allowed set” of an entry if 1) you’re a ‘member' of the group who is ‘manager’ for the entry, 2) as 1, but allow recursive groups, 3) you’re a ‘member’ of the group who is ‘manager’ for the entry’s ‘owner’, 4) as 3, but allow recursive groups, 5) as 3-4, but also allow recursive ‘owner’, or 6) if neither the entry nor any of its recursive owners has any ‘manager’ (and you have the “allow writes to unprotected entries” general access).
This is implemented as ACLs akin to this:
access to dn.subtree=“$our_root" attrs=@ourDistinguishedNameAttrs val.regex="^(.+)$$" by set.expand="( [${v1}]/manager*/member* | [${v1}]/manager* ) & user" break by set.expand="[${v1}]/manager" read stop by set.expand="[${v1}]/owner*/manager*/member* & user" break by set.expand="[${v1}]/owner*/manager" read stop by set.expand="[${v1}]/objectClass" break by * -a continue by * +z break
… which /works/, but performs rather badly when someone e.g. tries to read a group with hundreds of ‘member’ attributes.
Is there some feature I’m missing, or some way we can organize the ACLs, so that LDAP operations that only need read access won’t have to do the expensive write-protection checks?
Best regards -- Harald Meland