[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 

The logs:
  daemon: read activity on 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
  >>> 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
  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=""

  conn=0 op=5 SRCH base="dc=foo,dc=bar" scope=1 deref=0 
  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>, 
  str2filter "(objectClass=*)"
  begin get_filter
  end get_filter 0
  => bdb_search
  => bdb_dn2id("dc=bar,dc=foo,dc=bar")
  <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found 
  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=


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
> ---------------------------------------