[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
Here is a simplified configuration that can be used to replicate the
problem. I understand that such an error can not be easily triggered and
in that sense might be considered as a low priority issue, but then
again I believe it is worth mentioning. (I hope, I am not missing
anything here...)
#
#include schemas here
#
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to * by * none
argsfile /var/openldap/run/slapd.args
pidfile /var/openldap/run/slapd.pid
loglevel any
modulepath /opt/OpenLdap/sbin
moduleload back_bdb.la
moduleload back_relay.la
moduleload rwm.la
backend bdb
database bdb
suffix "dc=foo,dc=bar"
rootdn "uid=manager,dc=foo,dc=bar"
rootpw "secret"
directory /var/openldap/bdb
access to * by * read
database relay
suffix ""
relay "dc=foo,dc=bar" massage
access to * by * read
As you can see from the logs below, ops like this one:
SRCH base="dc=foo,dc=bar" scope=1 deref=0 filter="(objectClass=*)"
SRCH attr=hasSubordinates objectClass
fail, because slapd looks for an non-existent entry such as
bdb_dn2entry("dc=foo,dc=bar,dc=foo,dc=bar").
The logs:
=========
daemon: read activity on 11
connection_get(11)
connection_get(11): got connid=0
connection_read(11): checking for input on id=0
daemon: select: listen=7 active_threads=0 tvp=NULL
do_search
>>> dnPrettyNormal: <dc=foo,dc=bar>
<<< dnPrettyNormal: <dc=foo,dc=bar>, <dc=foo,dc=bar>
SRCH "dc=foo,dc=bar" 1 0
0 0 0
begin get_filter
PRESENT
end get_filter 0
filter: (objectClass=*)
=> get_ctrls
=> get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical)
<= get_ctrls: n=1 rc=0 err=""
attrs:
hasSubordinates
objectClass
conn=0 op=5 SRCH base="dc=foo,dc=bar" scope=1 deref=0
filter="(objectClass=*)"
conn=0 op=5 SRCH attr=hasSubordinates objectClass
slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2
==> limits_get: conn=0 op=5 dn="uid=manager,dc=foo,dc=bar"
[rw] searchDN: "dc=foo,dc=bar" -> "dc=foo,dc=bar,dc=foo,dc=bar"
>>> dnPrettyNormal: <dc=foo,dc=bar,dc=foo,dc=bar>
<<< dnPrettyNormal: <dc=foo,dc=bar,dc=foo,dc=bar>,
<dc=foo,dc=bar,dc=foo,dc=bar>
str2filter "(objectClass=*)"
begin get_filter
PRESENT
end get_filter 0
=> bdb_search
bdb_dn2entry("dc=foo,dc=bar,dc=foo,dc=bar")
=> bdb_dn2id("dc=bar,dc=foo,dc=bar")
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found
(-30989)
send_ldap_result: conn=0 op=5 p=3
send_ldap_result: err=10 matched="dc=foo,dc=bar" text=""
[rw] matchedDN: "dc=foo,dc=bar" -> ""
>>> dnPretty: <>
<<< dnPretty: <>
send_ldap_response: msgid=6 tag=101 err=32
conn=0 op=5 SEARCH RESULT tag=101 err=32 nentries=0 text=
Nikos
Pierangelo Masarati wrote:
> nvoutsin@noc.uoa.gr wrote:
>> While slapd does not segfault anymore, slapd insists to concatenate
>> unrelated database suffixes during search operations that look for attrs
>> such as hasSubordinates.
>>
>> I mention this here because it seems to be related somehow
>
> As I could see it working as expected (by me, at least), I suggest you
> cook a very simple example, consisting in two slapd.conf (one for the
> remote server, and one for the offending mixed local-proxy-relay setup),
> and as many data in LDIF format and submit it, so that you can show what
> you consider an incorrect behavior. Otherwise, I don't see any further
> indication of a bug.
>
> p.
>
>
>
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
>
> SysNet s.r.l.
> via Dossi, 8 - 27100 Pavia - ITALIA
> http://www.sys-net.it
> ---------------------------------------
> Office: +39 02 23998309
> Mobile: +39 333 4963172
> Email: pierangelo.masarati@sys-net.it
> ---------------------------------------
>
>