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

Re: access given to parent entry

> Pierangelo Masarati writes:
>>To: François Beretti <francois.beretti@enatel.com>
>>> I know that it is possible to give access on an entry to its parent (or
>>> grand-parent) entry, but it needs to write awful access control rules
>>> based on regular expressions.
>> (...)
>> I'm trying to figure out if anything like a range, or a set of branch
>> levels could be worth the effort...
> Or 'access by user to dn.subtree.expand=$0':-)
> Actually I've wanted to swap 'by' and 'to' now and then.

Something similar is already available in 2.3:

access to dn.subtree="dc=example,dc=com"
    by dn.exact,expand="$1" write

the "$1" expands to "dc=example,dc=com", while "$0" expands to the match.

However, it's nearly pointless, because ",expand=$1" can be replaced by

access to dn.subtree="dc=example,dc=com"
    by dn.exact="dc=example,dc=com" write

while "$0" can be replaced by

access to dn.subtree="dc=example,dc=com"
    by self write

It only becomes useful when used in conjunction with a regex on the <what>
side, which is what Francois intended to avoid.  I've been thinking about
other ways to obtain the "parent" or "ancestor" effect to no avail.  I
guess we'd need to go into some component matching stuff that decomposes
both the user's and the target's DN and sees if they do match at some
moint or so.  I don't think we need that effort.  I'm also unsure the
"parent" or "ancestor"'s stuff would be useful but in few selected cases. 
I don't want to litter my DSA with

access to *
    by parent write

because it's not immediately clear in what cases it's going to apply. 
However, a hypotetical

access to dn.self[2]="ou=People,dc=example,dc=com"
    by self[1] write

implying that write access to "[^,]+,([^,]+),ou=People,dc=example,dc=com"
would be granted to "$1,ou=People,dc=example,dc=com" might be of use, and
I understant it might be worth the effort of replacing a regex + expand +
match with a "," lookup + match for each ACL evaluation.


> Or even 'access when write...' so all the search operations won't
> bother to figure out if the user has write access to everything.

I see your point; I'm not sure, in this case if readability would improve:
it is very likely that you'd end up writing (almost) the same rules for
each privilege level...  However, it would be possible, in principle, to
work out programmatically if a rule will ever grant, say, write
permissions, and ignore it if, say, read access is checked.


Pierangelo Masarati

    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497