(ITS#8378) idlcache in back hdb doesn't update existing caches on a subtree rename, causing bad search results

[jonathan@phillipoux.net]

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