...

Full_Name: Jonathan Clarke Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.57.67.241)

This is similar to ITS #5191 (http://www.openldap.org/its/?findid=5191), except it happens with a subordinate LDAP database.

Consider this configuration : 8<--------------------------------------- database ldap suffix "o=test,o=sub" uri "ldap://localhost:1234" subordinate idassert-bind mode=none bindmethod=simple flags=prescriptive timeout=0 network-timeout=0 binddn="cn=svc,o=test" credentials="verysecret" idassert-authzFrom dn.regex:.* single-conn yes

overlay rwm rwm-suffixmassage "o=test,o=sub" "o=test"

database null suffix "o=sub" rootdn "cn=Manager,o=sub" rootpw secret overlay glue 8<---------------------------------------

A search with pagedResults control returns results as expected, but with a response control containing some garbage:

result: 0 Success control:: qOEpCDg0MC4xMTM1NTYuMS40LjMxOSBmYWxzZSBNSVFBQUFBSkFnRUFCQVFFQUFBQQ==

Some gdb'ing shows that backglue copies over the pointers to rs->sr_ctrls into glue_state->ctrls. But then, back-ldap's ldap_back_search does a ldap_controls_free() on rs->sr_ctrls. And so, the returned control contains garbage (mostly).

I haven't been able to come up with a patch yet, just commenting line 454 of back-ldap/search.c works. Running out of time for now...

Probably, backglue should rather ldap_controls_dup() them. However, in this case we need to make sure that the glued databases delete their own copy.

Also, I note that the glued paged response seems to work incorrectly. I made a simple test system, where the root database contains exactly one entry (the suffix) and a back-ldap is glued on top. If I request entries with a page size of 2, searching the suffix return 3 entries; subsequent searches return 2 entries from the proxy. I haven't figured out yet where the issue is.

p.