Full_Name: Jonathan Clarke Version: 2.4.44 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (176.182.31.158)

Hi there,

I found a bug in the handling of idl_cache when doing a MODRDN operation on an entry with children.

The existing code to add an entry in hdb_dn2id_add (dn2id.c) cleverly updates any existing IDL caches on the new parent and any grand-parents, both for "one" and "sub" level searches by adding the new entry in those cache lists.

However, if you MODRDN an entry that also has children, this same hdb_dn2id_add function is called, and will erroneously update the "sub" level search caches on the new parent and any grand-parents, adding only the new entry, and not it's children. The result is that a search that hits that IDL cache will return partial results, including the entry that was moved, but missing it's children.

You can observe this behaviour by compiling a standard OpenLDAP server, configuring a simple hdb backend, including a non-zero idlcachesize and running the following commands:

1) ldapadd < tesldldif 2) ldapsearch -b "ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" -s sub objectClass=organizationalUnit 3) ldapmodrdn -s "ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" "ou=1234,ou=Pending Inventories,ou=Inventorie2C2Ccn=rudder-configuration" "ou=1234" 4) ldapsearch -b "ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" -s sub objectClass=organizationalUnit

It is important to run the initial search in step 2, before the MODRDN operation itself, to ensure an IDL cache entry is created for that search. The final search in step 4 will not show the sub-entry ou=1234-sub,ou=1234.

The test.ldif file is here: ftp://ftp.openldap.org/incoming/test.ldif

I've created a quick'n'dirty patch to hide this issue, which detects the situation (if adding an entry that already has children, this is when the bug occurs) and simply removes the IDL cache to avoid future searches using it. It's available here: ftp://ftp.openldap.org/incoming/openldap-dn2id-modrdn-idlcache-sub-delete.patch.

A better solution would probably be to write the code to add each child of the new entry to existing caches, but I couldn't immediately see how to do this. Hopefully my patch above will easily show where this needs doing.

Regards, Jonathan