Schema change for olcAccess rules.

[Romain Komorn <rkomorn@dofc.org>]

Perhaps this is more of a development question than a usage question, but 
I thought this would be a decent forum to see if the idea gets any 
feedback (positive or negative).

I don't know how much others manipulate their olcAccess, or even if most 
people just maintain them in slapd.conf and restart slapd when necessary. 
I'm treating olcAccess entries more or less like firewall rules, adding 
and removing on the fly, thanks to the olcAccess attributes in backend DB 
definitions.

To me, it would seem a lot more convenient if the olcAccess in the backend 
DB definition pointed to a objectClass groupOfOlcAccess (for lack fo a 
better term). Each entry would have a single <what> attribute, and 
multiple  "<who> <access>" attributes. For example (in incorrect 
pseudo-LDIF format):

dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
[...]
olcAccessList: ou=bdb1OlcAccessList

----

dn: ou=bdb1OlcAccessList
ou: bdb1OlcAccessList
objectClass: groupOfOlcAccess

----

dn: cn=olc1,ou=bdb1OlcAccess
cn: olc1
objectClass: olcAccess
what: ou=people,dc=domain
whoaccess: {1}group="cn=readgroup,dc=domain" read
whoaccess: {2}cn="ldapadmin,dc=domain" write
whoaccess: {3}* none


----

Obviously, how useful this kind of change would be depends on how often 
people update their ACLs. In my case, I can see it happening often enough 
that I'd prefer to add/delete cn's or "whoaccess" attributes, rather than 
editing olcAccess attributes in the backend config. I'd want the backend 
config to be fairly static, as opposed to the ACLs in my environment 
which would be fairly dynamic.


Feel free to tell me it's a terrible idea. I may not know enough 
background information about how slapd works and how this type of schema 
change would affect performance.

Romain Komorn