Negated ACL fields?

[Rein Tollevik <rein@basefarm.no>]

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, 
i.e:

 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 ...

as would:

 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 
attributes.

Comments?

--
Rein Tollevik
Basefarm AS