On 3/7/2011 2:18 πμ, Howard Chu wrote:
We've been discussing this problem (ACL rule descriptions) for quite a while. My current thinking is that somehow we can use attribute options to help. Visually it might be better to associate the option with the original attribute, e.g. olcAccess: olcAccess;x-comment: This would require defining a new (and strange) type of attribute option though, since the value with the option has no relation (syntactically) to the original attribute type.
The other alternative is to add a generic description attribute, and tag it with the attribute that a comment refers to: description;x-olcAccess: blah blah blah
This is a lot simpler for us to implement.
Sorry for jumping back to this issue again, but I think that this is an important issue from an administrator's point of view and AFAIK it has not been tackled yet.
I would like to suggest two possible (alternative) changes on the olcAccess attribute:
1. In order to achieve proper display order of olcAccess rules (since most clients automatically sort values based on characters), I would like to ask that the default numbering is not {0}...{n}, but {00000} ... {n} where n is a 5-digit integer (I will depict this as DDDDD). This scheme would support 100.000 (0 - 99999) rules and I believe that it would be sufficient for all practical needs. (If not, it could be made a 6 digit figure; if it is too much already, it could be a 4-digit figure.) Please note that proper ordering/listing of these rules is important in everyday administration!
As an example, instead of:
olcAccess: {0}to dn.subtree=... olcAccess: {1}to dn.regex=...
use:
olcAccess: {00000}to dn.subtree=... olcAccess: {00001}to dn.regex=...
2. On comments about ACL rules: numbering could provide a possible solution (if it's technically feasible and software architects consider it appropriate). olcAccess could take two possible values, one for comments and one for the rule itself; "numbering" could in this case be: {DDDDDc} and {DDDDDr} where D is a digit, c refers to a comment and r refers to the rule itself. This approach would have the advantage that most ldap clients would display rules and comments together in proper sequence. Of course {DDDDDc} would be optional. OpenLDAP software would:
1. Automatically add the {DDDDDr} tag (for new rules), as it now adds an {X} numeric index. 2. Allow admins to manually add olcAccess values starting with a {DDDDDc} and it would ignore them when evaluating rules. 3. This scheme would allow the automatic inclusion of existing ACL comments when converting from slapd.conf, by including {DDDDDc} values for the olcAccess attribute, as needed.
As an example:
olcAccess: {00000c}*** Provide access to subtree xxxx *** olcAccess: {00000r}to dn.subtree=... olcAccess: {00001c}*** Provide access to whatever *** olcAccess: {00001r}to dn.regex=...
To take this a bit further, multiple {DDDDDc} could be allowed and it would be up to the administrator(s) to use an initial string to allow proper sorting of such comments (for example {00000c}[00]...{00000c}[01] etc.). OpenLDAP software would ignore these values in evaluating rules anyway.
Just my 2c on an everyday maintenance problem, or a seed for further or other proposals.
By the way, a question: in case someone manually deletes (accidentally or intentionally) a rule so that a gap in numbering occurs, will OpenLDAP continue to evaluate subsequent rules? For example, if someone deletes existing rule {12} (current numbering scheme), will the system evaluate ACLs after {11} (like {13}, {14} etc.)?
Thanks for your time, Nick