(ITS#5418) Syncrepl filters are evaluated using the wrong DN

[roessner@capcom.de]

Full_Name: Ralph Rößner
Version: 2.4.8
OS: Debian Linux
URL: ftp://ftp.capcom.de/pub/CPS/openldap-ITS-20080312/
Submission from: (NULL) (146.140.221.89)


When syncreplication is run in refreshAndPersist mode and it is limited to
certain objects by a "filter=..." expression and one of these objects is
modified then the attributes needed to check the filter expression are accessed
using the rights of the DN that the modifying connection is bound to, not those
of the DN that the replication connection is bound to. This can result in
modifications not being propagated to the consumer server.

This was encountered in the wild when a user successfully changed some service
password but found that the change was not reflected by the consumer slapd that
he was subsequently trying to authenticate to. The same change requested by a
maintenance tool (under a different bind dn) was replicated. Turning on ACL
tracing showed up the behaviour described above.

I have created a demonstration configuration and data set, available at the
provided ftp URL and summarized in the "index" file there.

The demonstration features a replication that is restricted to object that have
the "replicate" attribute set to "yes", a user object
"uid=user,ou=subtree,o=test" that is allowed to change its password but not
allowed to read the "replicate" attribute, a maintenance object
"uid=maintainer,o=test" that is allowed to create or modify user entries,
including their "replicate" attribute, and a replication object
"uid=replicator,o=test" that is used as bind dn for the replication and is
allowed to read everything that has the "replicate" attribute set to "yes".

I have then changed the userPassword attribute of the user object, using the
ldappasswd tool, and traced the provider slapd. The logs show that after the
modification is done, the "replicate" attribute is accessed, and the ACLs are
checked using the dn that the modifying connection is bound to (which is the
user dn in the case of the first log and the maintenance dn in the second). Only
the modification made by the maintainer is propagated, the one made by the user
is not, as shown by the logs and by the ldapsearch results provided with the
files.

Allowing access to the "replicate" attribute for everyone (as in the
"slapd-workaround.conf") works around the problem. The third slapd log file
shows that now even a modification made by the user dn is being propagated.

Pierangelo Masarati has already suggested a patch for this behaviour on the
openldap-software list (included with the files). After applying this patch the
behaviour changes as shown in the last provided slapd log file, i.e. the access
checks to the "replicate" attribute are made with respect to the replication dn,
and do not any more depend on the dn that requested the modification. This fixes
the problem for me in the demonstration setup.

Sincerely,
Ralph Rößner