[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Wishes for set ACLs
Hallvard B Furuseth wrote:
1.
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 []
otherwise.
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
characters.
Should be easy; I'd favor the first choice. I guess you don't want an
'||' because the '|' already does the trick.
2.
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 ",".
Right. In this case, a generic mechanism might be useful, e.g.
something like a cast:
"[cn=] + <DNescape:user/cn> + [,o=foo]"
looks like we're running out of operators...
3.
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.
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.
"self/uid & <DNunescape:[%1]>"
so that the same cast mech could be used with many different string
mucking functions.
p.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497