[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#6997) Segmentation fault when using slapo-rwm and slapo-chain



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