Re: ACI/ACL based on entry attribute values

[Ugen <ugen@xonix.com>]

You mean this: http://www.openldap.org/faq/data/cache/452.html ?
I haven't seen set syntax documented in administrator guide. In any
case, it seems close enough but still won't allow for the case i am
describing.

The text in http://www.openldap.org/faq/data/cache/451.html states that
i can use regular expression substrings, and refer to them later as a $x 
vars.
Also not something in the admin doc, bu this is getting warmer :)

That paragraph seems to suggest that if i match a <what> dn against a 
regular
expression, then the <who> dn can later be matched based on substrings of
<what>. Reversing the matching order (or being able to specify it in the 
ACL)
would do the trick ! I.e. if i first can select a substring of the user 
DN (say, the
entire DN) and then match it against target DN (dn=/.*$1$/ to anchor the 
user
DN to the right/top of target)  we have a deal:)

More expanded syntax would include similar matches and substring storage for
attributes, i.e.:

<who> ::= ....
        attrpick <attrname>=<regexp with substrings>
        userattrmatch <attrname>=<regexp with substrings>

<what> ::= ....
        attrpick <attrname>=<regexp with substrings>
        targetattrmatch <attrname>=<regexp with substrings>
Order of execution is as follows:
1) pick attributes from current user
2) pick attributes from current target
3) match values picked from the user entry to the target entry, if no match
   this acl is denied
4) match values picked from target entry to the user entry, deny if no match
Note: $x variables will form to distinct sets - one from user attributes 
and one
from target attributes, used in their match counterpart.

What we have done, is crossmatched attribute values (including but
not limited to DN) between the user and the target. This will allow for all
cases i described, yet would not be too hard to process (we don't get 
multiple
entry results to search through, just a lot of string matching:)

Examples:

access to targetattrmatch dn=".*$1$"
   by attrpick dn="(.*)" write

I just let anyone above any entry have write access to
it's descendants.

Even more powerful would be a mix of this with LDAP
filters (such as proposed in sets?) to be able to say something like
this (sorry. no more BNF:)

access to targetattrmatch dn=".*$1$"
   by filterpick (&(dn="(.*)")(objectClass="specialOrgManager")

This basically expands filter "wildcard" match to a full
regexp pattern match with substring storage. We already
have ldap filter matching for a user AFAIK.

--Ugen