Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault

[masarati@aero.polimi.it]

OK, I've found the problem, and it seems to be a configuration problem. 
Please read below.

> Here is the slapd.conf used in the test:
>
>
> #
> # See slapd.conf(5) for details on configuration options.
> # This file should NOT be world readable.
> #
> include         /home/build/rel-openldap/etc/openldap/schema/core.schema
>
> # Define global ACLs to disable default read access.
>
> # Do not enable referrals until AFTER you have a working directory
> # service AND an understanding of referrals.
> #referral       ldap://root.openldap.org
>
> pidfile         /home/build/rel-openldap/var/run/slapd.pid
> argsfile        /home/build/rel-openldap/var/run/slapd.args
>
> # Load dynamic backend modules:
> # modulepath    /home/build/rel-openldap/libexec/openldap
> # moduleload    back_bdb.la
> # moduleload    back_hdb.la
> # moduleload    back_ldap.la
>
> # Sample security restrictions
> #       Require integrity protection (prevent hijacking)
> #       Require 112-bit (3DES or better) encryption for updates
> #       Require 63-bit encryption for simple bind
> # security ssf=1 update_ssf=112 simple_bind=64
>
> # Sample access control policy:
> #       Root DSE: allow anyone to read it
> #       Subschema (sub)entry DSE: allow anyone to read it
> #       Other DSEs:
> #               Allow self write access
> #               Allow authenticated users read access
> #               Allow anonymous users to authenticate
> #       Directives needed to implement policy:
> # access to dn.base="" by * read
> # access to dn.base="cn=Subschema" by * read
> # access to *
> #       by self write
> #       by users read
> #       by anonymous auth
> #
> # if no access controls are present, the default policy
> # allows anyone and everyone to read anything but restricts
> # updates to rootdn.  (e.g., "access to * by * read")
> #
> # rootdn can always read and write EVERYTHING!
>
> database       perl
> suffix         "ou=perl,dc=my-domain,dc=com"

^^ This is the suffix where the instance of back-perl is rooted at

> subordinate
> perlModulePath  /home/build/rel-openldap/etc/openldap
> perlModule      SampleLDAP
>
> #######################################################################
> # BDB database definitions
> #######################################################################
>
> database        bdb
> suffix          "dc=my-domain,dc=com"
> rootdn          "cn=Manager,dc=my-domain,dc=com"
> # Cleartext passwords, especially for the rootdn, should
> # be avoid.  See slappasswd(8) and slapd.conf(5) for details.
> # Use of strong authentication encouraged.
> rootpw          secret
> # The database directory MUST exist prior to running slapd AND
> # should only be accessible by the slapd and slap tools.
> # Mode 700 recommended.
> directory       /home/build/rel-openldap/var/openldap-data
> # Indices to maintain
> index   objectClass     eq
>
>
> And here is the slapcat output when the perl database is disabled in
> slapd.conf to prevent the crash:
>
>
> dn: dc=my-domain,dc=com
> objectClass: top
> objectClass: dcObject
> objectClass: organization
> o:: bXlkb21haW4uY29tIA==
> dc: my-domain
> structuralObjectClass: organization
> entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d
> creatorsName: cn=Manager,dc=my-domain,dc=com
> createTimestamp: 20100406120241Z
> entryCSN: 20100406120241.310422Z#000000#000#000000
> modifiersName: cn=Manager,dc=my-domain,dc=com
> modifyTimestamp: 20100406120241Z
>
> dn: ou=real,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> structuralObjectClass: organizationalUnit
> entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2
> creatorsName: cn=Manager,dc=my-domain,dc=com
> createTimestamp: 20100406120446Z
> ou: real
> entryCSN: 20100406120458.545769Z#000000#000#000000
> modifiersName: cn=Manager,dc=my-domain,dc=com
> modifyTimestamp: 20100406120458Z
>
> dn: ou=perl,dc=my-domain,dc=com

^^^ An entry with the same DN exists in the superior database.  As a
consequence, this entry is returned by back-bdb's tool functions, but
backglue tries to release it using back-perl.  Since back-perl does not
have any tool functions, what is considered a safe replacement is used. 
Unfortunately, the safe replacement doesn't know how to deal with
read-only entries returned by back-bdb.  The solution consists in:

- temporarily commenting the instance of back-perl

- removing this entry from your back-bdb

- re-enabling the instance of back-perl

A follow-on to this ITS could be to devise a means to detect whether a
superior database contains entries that belong to a subordinate one, and
warn the administrator of the inconsistency.

p.