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