Re: acl problem

[Dieter KlÃnter <dieter@dkluenter.de>]

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

-- 
http://sys4.de