[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Loading LDAP schema files into cn=config



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