Issue 8378 - idlcache in back hdb doesn't update existing caches on a subtree rename, causing bad search results
Summary: idlcache in back hdb doesn't update existing caches on a subtree rename, caus...
Status: RESOLVED WONTFIX
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.44
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
: 8382 (view as issue list)
Depends on:
Blocks:
 
Reported: 2016-02-23 01:11 UTC by Jonathan
Modified: 2021-04-01 16:27 UTC (History)
2 users (show)

See Also:


Attachments
test.ldif (1.22 KB, text/x-ldif)
2020-03-22 03:50 UTC, Quanah Gibson-Mount
Details
openldap-dn2id-modrdn-idlcache-sub-delete.patch (1.27 KB, text/plain)
2020-03-22 03:51 UTC, Quanah Gibson-Mount
Details
openldap-dn2id-modrdn-idlcache-sub-delete-2.patch (1.60 KB, text/plain)
2020-03-22 03:52 UTC, Quanah Gibson-Mount
Details

Note You need to log in before you can comment on or make changes to this issue.
Description Jonathan 2016-02-23 01:11:55 UTC
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
Comment 1 Jonathan 2016-02-29 18:44:06 UTC
The patch I originally sent works only for MODRDN operations, but causes 
a segfault on plain old ADD operations in some cases.

This is caused by the hdb_dn2id_children function trying to update dkids 
inside a non-initialised structure. I figure that if we don't have the 
structure we don't need to update it, since this function is mostly a 
"search" function. Hope that makes sense.

A new patch is here: 
ftp://www.openldap.org/incoming/openldap-dn2id-modrdn-idlcache-sub-delete-2.patch

Jonathan

Comment 2 OpenLDAP project 2017-09-11 16:30:19 UTC
has patch
Comment 3 Quanah Gibson-Mount 2017-09-11 16:30:19 UTC
changed notes
Comment 4 Quanah Gibson-Mount 2020-03-22 03:50:39 UTC
Created attachment 639 [details]
test.ldif
Comment 5 Quanah Gibson-Mount 2020-03-22 03:51:37 UTC
Created attachment 640 [details]
openldap-dn2id-modrdn-idlcache-sub-delete.patch
Comment 6 Quanah Gibson-Mount 2020-03-22 03:52:16 UTC
Created attachment 641 [details]
openldap-dn2id-modrdn-idlcache-sub-delete-2.patch
Comment 7 Quanah Gibson-Mount 2020-03-22 03:55:47 UTC
back-bdb/hdb deprecated in 2.4
deleted from 2.5
Comment 8 Quanah Gibson-Mount 2020-03-22 03:59:36 UTC
*** Issue 8382 has been marked as a duplicate of this issue. ***