[Date Prev][Date Next]
Re: Wishes for set ACLs
Hallvard B Furuseth wrote:
Should be easy; I'd favor the first choice. I guess you don't want an
'||' because the '|' already does the trick.
It would be nice to have boolean operators on sets. That allows
e.g. 'members of posixGroup A can access members of posixGroup B':
(user/uid & [cn=A]/memberUid) && (this/uid & [cn=B]/memberUid)
where '&&' would return the empty set if one of the sets are empty, and
either the set  or the last set otherwise.
or it could be
(user/uid & [cn=A]/memberUid)@bool & (this/uid & [cn=B]/memberUid)@bool
where <set>@bool returns the empty set if <set> is empty and 
Or spell @bool as just @ or ? or whatever, but we'll probably want more
transformations later so maybe it's best to not use up too many special
2.Right. In this case, a generic mechanism might be useful, e.g.
something like a cast:
An operator would be useful which escaped the members of a set as DNs.
"[cn=] + user/cn + [,o=foo]" is wrong if the cn contains ",".
"[cn=] + <DNescape:user/cn> + [,o=foo]"
looks like we're running out of operators...
3.I think that was the intended usage (with pros 'n' cons), i.e. allow
rules to be built dynamically by means of regexes. Maybe another
operator could be defined to get post-dereferencing, e.g.
Maybe an un-escaping operator too, for "self/uid & [$1]" where $1
comes from a regular expression match in the 'access to' clause.
Oh, yet another:
Expand $<digit> after parsing the set instead of before parsing, so
e.g. [$1] doesn't break if $1 contains a ']'. That probably means
$<digit> can only be used in  and in the attribute name after '/'.
At the same time, one could parse the set when the config file is
read instead of when the access statement is evaluated.
"self/uid & <DNunescape:[%1]>"
so that the same cast mech could be used with many different string
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497