Re: Loading LDAP schema files into cn=config

[Nick Milas <nick@eurobjects.com>]

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