Am Fri, 27 Dec 2013 18:12:20 +0000 schrieb "Mundry, Marvin" Marvin.Mundry@uni-hamburg.de:
I have encountered an effect that I believe is a bug, but I might be wrong. It would be nice if someone could confirm that my acls should be working, or in case they should not, give me a hint what I am doing wrong.
Here is what I am trying to archive:
- there is one ldap provider (master) server that contains all
attributes that are relevant for my organisation
- on the master there is a user allowing a highly secured
consumer(slave) ldap server the replication of all attributes from the master
- on the master there is a user allowing a low-security
consumer(slave) ldap server the replication of all attributes from the master except some critical ones
- on the master there is a user (cn=provisioninguser) that can read
the accesslog. it is used by scripts to e.g. notify non-ldap systems of password changes.
I would like to put the acls for the replication users (high and low security ldap slaves) on the databases and not the frontend to avoid accidental modifications. All other acls should be on the frontend.
If I configure all my acls on the frontend only everything works as I think it should. If some acls are on the database the results are rather weird ( the cn=provisioninguser can see only one value of the multi-valued reqMod attribte)
The following acl snippet only deals with accesslog access which is where I encounter the problem:
dn: olcDatabase={2}hdb,cn=config olcAccess: {0}to dn.subtree="cn=accesslog" attrs=reqMod val.regex="^topSecretAttribute:.*" by dn.base="cn=replicationuser,dc=organisation,dc=com" read by dn.base="cn=replication_low_security,dc=organisation,dc=com" none by * break
the break rule will be ignored, as 'none' is the implicit last rule.
[...]
run slapd with -dacl
-Dieter