[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
- From: masarati@aero.polimi.it
- Date: Tue, 6 Apr 2010 16:39:31 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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.