[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