Ralph Rößner wrote:
I have noticed (as of 2.4.7) an interaction of searchAndPersist syncrepl, search filters, and access rules that looks weird to me. Before I call it a bug (and submit to ITS) I'd like to ask whether I'm not just missing the point and everything is working as intended.
Two hints: 1. Whenever I suspect something strange to happen I try to reproduce it with a more recent release version (2.4.8 as for now) to check whether it might has been already fixed in the meantime and 2. with a minimal configuration without confidential information which I then post to the mailing list.
For 1. please also consult file CHANGES of source distribution 2.4.8. The list of changes 2.4.7->2.4.8 is quite long.
So here is the situation: We replicate just part of the provider data by annotating the objects to replicate with an extra replication info attribute. Access to that attribute is restricted.
Restricted to which identities? I guess ACLs for this are added to the provider's slapd.conf.
Now when an object is change, we observe this:
What does "we observe this" mean? Did you implemented your own syncrepl client? Or are you just using two OpenLDAP servers with syncrepl?
If the change is made by a user who has read access to the replication info attribute then the change is replicated. Otherwise it is not.
I don't get this. Are you sure that you literally mean what you write here?
Normally if you implement (partial) replication between two slapd instances with syncrepl it does not matter who modified an entry. Or do you have a filter in your syncrepl-statement containing a component (modifiersName=<some-DN>)?
It appears that the replication filter is evaluated using the access rights of the user making the modification, not those of the replication user.
???
The provider simply applies whatever ACLs you defined at the provider to the search request sent by the binddn which is defined in your syncrepl-statement in the consumer's slapd.conf.
Otherwise I'll pack up configs,
Let us see the config files of the provider (master) and the consumer (slave).
Ciao, Michael.