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