[Date Prev][Date Next]
Negated ACL fields?
I have some ACLs where the same <who> statements are included in all the
<by> fields. Rather than re-evaluating them each time I would like to
quickly skip the entire ACL by negating the statements. I.e, rather than:
access to * by <who1> <who2> ... by <who1> <who3> ...
I'd like to say:
access to * by !<who1> break by <who2> ... by <who3> ...
And, I would like to negate the individual <who> statements, not
necessarily all of them. This would also immediately make it useful to
include the same type of <who> statement more than once in a <by> field,
access to * by !dn=something !dn=something-else ...
Neither of these can be easily implemented with the current internal
representation of the <who> statements, as each type is now an element
in the Access struct that represents the entire <by> field. To do it
this would have to be changed into a struct which includes a list of
<who> statements, evaluated in the order they are defined.
Making this change is likely to alter the order in which existing ACL
<who> statements are evaluated, but their combined effect should be the
same since they are effectively and'ed together. Unless evaluating any
of them have other side-effects that is, which they don't have as far as
I know. This would also give the administrator full control of the
order in which the statements are evaluated, which I find to be a Good
Thing. As of now relatively "cheap" statements like testing the
security strength factors are evaluated after potential "costly"
operations like set statements.
If the <who> statements are to be changed like this it makes sense to do
the same to the <what> fields as well. Which again raises the question
as to how regexp captions should be handled. For negated fields it is
meaningless to capture any regexp fields, so they should not define nor
alter any already captured sub-matches. For the other I find it most
natural that the last evaluated <what> field defines the sub-matches for
that <what> type, and making the sub-matches immediately accessible in
the <what> fields that follows them.
Allowing <what> fields to be negated would also eliminate the need to
define "artificial" objectclasses to allow negated "attrs" lists. I.e,
assuming the "attrlistClass" objectclass allows "attr1" and "attr2", the
following would be equivalent:
access to attrs=@attrlistClass by ...
access to !attrs=!attrlistClass by ...
access to attrs=attr1,attr2 by ...
access to attrs=!attrlistClass by ...
access to !attrs=@attrlistClass by ...
access to !attrs=attr1,attr2 by ...
Assuming the "sufficient" control discussed in my previous posting is
also accepted I could quickly grant read access to all attributes in an
entry, leaving the actual choice at to whether they can be read to the
access granted to the entry itself, using the following (after other
ACLs that protects any non-readable attributes):
access to !attrs=entry,children by * read sufficient
Attempting the same with write would be disastrous though, as write
access to an attribute do not require write access to the "entry" pseudo
attribute, whereas read access to the "entry" is required to read its