Full_Name: Manuel Gaupp Version: 2.4.26 OS: Linux 2.6.18 (CentOS 5.6 x86_64) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.208.112.253) Under the following circumstances OpenLDAP crashes when a chained search does not return with result code 0: - "rwm" overlay used in a global context - "chain" overlay used in a database specifix context (gdb) bt #0 0x0000000400040004 in ?? () #1 0x000000000042e5c7 in slap_cleanup_play (op=0x197834b0, rs=0x42a07ca0) at result.c:539 #2 0x000000000042ef9b in send_ldap_response (op=0x197834b0, rs=0x42a07ca0) at result.c:724 #3 0x000000000042fcf9 in slap_send_ldap_result (op=0x197834b0, rs=0x42a07ca0) at result.c:851 #4 0x00000000004d982a in ldap_chain_response (op=0x197834b0, rs=0x42a07ca0) at chain.c:1165 #5 0x00000000004820ca in over_back_response (op=0x197834b0, rs=0x42a07ca0) at backover.c:237 #6 0x000000000042e535 in slap_response_play (op=0x197834b0, rs=0x42a07ca0) at result.c:505 #7 0x000000000042ef78 in send_ldap_response (op=0x197834b0, rs=0x42a07ca0) at result.c:579 #8 0x000000000042fcf9 in slap_send_ldap_result (op=0x197834b0, rs=0x42a07ca0) at result.c:851 #9 0x00000000004928f0 in bdb_search (op=0x197834b0, rs=0x42a07ca0) at search.c:499 #10 0x0000000000482352 in overlay_op_walk (op=0x197834b0, rs=0x42a07ca0, which=op_search, oi=0x196f3bb0, on=0x0) at backover.c:671 #11 0x00000000004828b7 in over_op_func (op=0x197834b0, rs=0x42a07ca0, which=op_search) at backover.c:723 #12 0x0000000000421cf9 in fe_op_search (op=0x197834b0, rs=0x42a07ca0) at search.c:402 #13 0x0000000000482352 in overlay_op_walk (op=0x197834b0, rs=0x42a07ca0, which=op_search, oi=0x1970fd30, on=0x0) at backover.c:671 #14 0x00000000004828b7 in over_op_func (op=0x197834b0, rs=0x42a07ca0, which=op_search) at backover.c:723 #15 0x0000000000422505 in do_search (op=0x197834b0, rs=0x42a07ca0) at search.c:247 #16 0x000000000041fa95 in connection_operation (ctx=0x42a07d70, arg_v=<value optimized out>) at connection.c:1138 #17 0x0000000000503d5c in ldap_int_thread_pool_wrapper (xpool=0x196beee0) at tpool.c:685 #18 0x000000316820673d in start_thread () from /lib64/libpthread.so.0 #19 0x0000003167ad44bd in clone () from /lib64/libc.so.6 OpenLDAP 2.4.26 was built using: ./configure --enable-rewrite --enable-ldap --enable-rwm --enable-bdb This issue can be reproduced using the following configuration (referred as 'slapd.conf.proxy') ------------------------------------------ overlay rwm # There might be some rewrite directives database bdb suffix "o=example" rootdn "cn=admin,o=example" rootpw secret directory /root/db.proxy overlay chain chain-return-error true chain-uri "ldap://localhost:38977" ------------------------------------------ The process is started on port 389 with plain ldap /usr/local/libexec/slapd -f slapd.conf.proxy -h "ldap://localhost:389" Create the following entry in this server: dn: cn=ldap,o=example objectclass: extensibleObject objectclass: referral ref: ldap://localhost:38977/cn=real,o=example To reproduce the error there has to be another server where the referral points to. It contains the following minimal configuration: (referred as 'slapd.conf.server') ------------------------------------------ database bdb suffix "cn=real,o=example" rootdn "cn=admin,cn=real,o=example" rootpw secret directory /root/db.server ------------------------------------------ The process is started on port 38977 with plain ldap /usr/local/libexec/slapd -f slapd.conf.server -h "ldap://localhost:38977" Using the following ldapsearch, slapd crashes: ldapsearch -h localhost -p 389 -D "cn=admin,o=example" -w secret \ -x -b "ou=abc,cn=ldap,o=example" 1.1 Whereas the following ldapsearch returns with "success" ldapsearch -h localhost -p 389 -D "cn=admin,o=example" -w secret \ -x -b "cn=ldap,o=example" 1.1 Deactivating the "rwm" overlay prevents from this issue. So I think the problem can be found somewhere in the rwm sources. -- Manuel
> Full_Name: Manuel Gaupp > Version: 2.4.26 > OS: Linux 2.6.18 (CentOS 5.6 x86_64) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.208.112.253) > > > Under the following circumstances OpenLDAP crashes when a chained search > does not return with result code 0: > - "rwm" overlay used in a global context > - "chain" overlay used in a database specifix context > > (gdb) bt > #0 0x0000000400040004 in ?? () > #1 0x000000000042e5c7 in slap_cleanup_play (op=0x197834b0, rs=0x42a07ca0) > at result.c:539 > #2 0x000000000042ef9b in send_ldap_response (op=0x197834b0, > rs=0x42a07ca0) > at result.c:724 > #3 0x000000000042fcf9 in slap_send_ldap_result (op=0x197834b0, > rs=0x42a07ca0) at result.c:851 > #4 0x00000000004d982a in ldap_chain_response (op=0x197834b0, > rs=0x42a07ca0) at chain.c:1165 > #5 0x00000000004820ca in over_back_response (op=0x197834b0, > rs=0x42a07ca0) > at backover.c:237 > #6 0x000000000042e535 in slap_response_play (op=0x197834b0, > rs=0x42a07ca0) > at result.c:505 > #7 0x000000000042ef78 in send_ldap_response (op=0x197834b0, > rs=0x42a07ca0) > at result.c:579 > #8 0x000000000042fcf9 in slap_send_ldap_result (op=0x197834b0, > rs=0x42a07ca0) at result.c:851 > #9 0x00000000004928f0 in bdb_search (op=0x197834b0, rs=0x42a07ca0) > at search.c:499 > #10 0x0000000000482352 in overlay_op_walk (op=0x197834b0, rs=0x42a07ca0, > which=op_search, oi=0x196f3bb0, on=0x0) at backover.c:671 > #11 0x00000000004828b7 in over_op_func (op=0x197834b0, rs=0x42a07ca0, > which=op_search) at backover.c:723 > #12 0x0000000000421cf9 in fe_op_search (op=0x197834b0, rs=0x42a07ca0) > at search.c:402 > #13 0x0000000000482352 in overlay_op_walk (op=0x197834b0, rs=0x42a07ca0, > which=op_search, oi=0x1970fd30, on=0x0) at backover.c:671 > #14 0x00000000004828b7 in over_op_func (op=0x197834b0, rs=0x42a07ca0, > which=op_search) at backover.c:723 > #15 0x0000000000422505 in do_search (op=0x197834b0, rs=0x42a07ca0) > at search.c:247 > #16 0x000000000041fa95 in connection_operation (ctx=0x42a07d70, > arg_v=<value optimized out>) at connection.c:1138 > #17 0x0000000000503d5c in ldap_int_thread_pool_wrapper (xpool=0x196beee0) > at tpool.c:685 > #18 0x000000316820673d in start_thread () from /lib64/libpthread.so.0 > #19 0x0000003167ad44bd in clone () from /lib64/libc.so.6 > > OpenLDAP 2.4.26 was built using: > ./configure --enable-rewrite --enable-ldap --enable-rwm --enable-bdb > > This issue can be reproduced using the following configuration > (referred as 'slapd.conf.proxy') > ------------------------------------------ > overlay rwm > # There might be some rewrite directives > database bdb > suffix "o=example" > rootdn "cn=admin,o=example" > rootpw secret > directory /root/db.proxy > overlay chain > chain-return-error true > chain-uri "ldap://localhost:38977" > ------------------------------------------ > The process is started on port 389 with plain ldap > /usr/local/libexec/slapd -f slapd.conf.proxy -h "ldap://localhost:389" > > Create the following entry in this server: > dn: cn=ldap,o=example > objectclass: extensibleObject > objectclass: referral > ref: ldap://localhost:38977/cn=real,o=example > > To reproduce the error there has to be another server where the referral > points to. It contains the following minimal configuration: > (referred as 'slapd.conf.server') > ------------------------------------------ > database bdb > suffix "cn=real,o=example" > rootdn "cn=admin,cn=real,o=example" > rootpw secret > directory /root/db.server > ------------------------------------------ > The process is started on port 38977 with plain ldap > /usr/local/libexec/slapd -f slapd.conf.server -h "ldap://localhost:38977" > > Using the following ldapsearch, slapd crashes: > ldapsearch -h localhost -p 389 -D "cn=admin,o=example" -w secret \ > -x -b "ou=abc,cn=ldap,o=example" 1.1 > > Whereas the following ldapsearch returns with "success" > ldapsearch -h localhost -p 389 -D "cn=admin,o=example" -w secret \ > -x -b "cn=ldap,o=example" 1.1 > > Deactivating the "rwm" overlay prevents from this issue. So I think the > problem can be found somewhere in the rwm sources. I'm afraid that's unavoidable given the stacking order of the overlays. This will likely be fixed only when ITS#6166 is addressed, i.e. in OpenLDAP 2.5. p.
changed notes changed state Open to Suspended
moved from Incoming to Software Bugs
I think it's worth to note that such a setup with this stacking order works with OpenLDAP 2.4.23 (in a more complex variant done by Manuel). So the big question is what was changed in 2.4.24+ which leads to the crash? Ciao, Michael.
needs ITS#6166