Hello list,
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.
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. Now when an object is change, we observe this: 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. It appears that the replication filter is evaluated using the access rights of the user making the modification, not those of the replication user.
If someone can tell me that this is not a problem because ... whatever reason then I'm interested to know. Otherwise I'll pack up configs, logs, etc. and file a bug report.
Sincerely, Ralph Rößner
On Fri, 7 Mar 2008, Ralph RöÃ~_ner wrote:
Otherwise it is not. It appears that the replication filter is evaluated using the access rights of the user making the modification, not those of the replication user.
IIRC, the syncrepl client should connect to the provider, bind as the identity configured on the syncrepl client, then perform a search with the filter configured on the syncrepl client.
As such, the "user making the modification" should never enter into the algorithm. You should be able to verify this with "slapd -d access" on the provider. Give it a try and see if it looks sane, i.e. you should only see references to the identity configured on the syncrepl client in the course of a syncrepl connection.
Aaron Richton wrote:
As such, the "user making the modification" should never enter into the algorithm. You should be able to verify this with "slapd -d access" on the provider. Give it a try and see if it looks sane, i.e. you should only see references to the identity configured on the syncrepl client in the course of a syncrepl connection.
Just for the records, there is no "access" log level. I assume you mean "acl".
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
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.
Ralph Rößner wrote:
Hello list,
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.
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. Now when an object is change, we observe this: 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. It appears that the replication filter is evaluated using the access rights of the user making the modification, not those of the replication user.
If someone can tell me that this is not a problem because ... whatever reason then I'm interested to know. Otherwise I'll pack up configs, logs, etc. and file a bug report.
Please check after applying this patch:
diff -u -r1.215 syncprov.c --- ./servers/slapd/overlays/syncprov.c 10 Feb 2008 23:19:43 -0000 1.215 +++ ./servers/slapd/overlays/syncprov.c 7 Mar 2008 23:30:34 -0000 @@ -1209,7 +1209,7 @@ }
/* check if current o_req_dn is in scope and matches filter */ - if ( fc.fscope && test_filter( op, e, ss->s_op->ors_filter ) == + if ( fc.fscope && test_filter( ss->s_op, e, ss->s_op->ors_filter ) == LDAP_COMPARE_TRUE ) { if ( saveit ) { sm = op->o_tmpalloc( sizeof(syncmatches), op->o_tmpmemctx );
If it fixes your issue, please file an ITS.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Thanks everyone for your quick replies. I will build a minimal testing environment and then try out the patch provided by Mr. Masarati.
While there are "-d trace,acl,sync" logs at this point (i.e. I'm not just randomly guessing), they were generated using a copy of our production configuration and are much too voluminous to put on the list. Testing that patch should produce more readable output.
Ralph
openldap-software@openldap.org
-
Aaron Richton -
Michael Ströder -
Pierangelo Masarati -
Ralph Rößner