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

(ITS#6455) Able to crash slapd while using back_ldap

Full_Name: J
Version: 2.4.20
OS: Debian-Lenny/amd64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (

Host running Debian Lenny amd64 is experiencing a strange issue.  slapd is
segfaulting for no obvious reason. Syslog output:

Jan 15 19:29:59 ldapc1 kernel: [10702.262741] slapd[3218]: segfault at 40 ip
7fb2b4829875 sp 44d90940 error 4 in back_ldap-2.4.so.2.5.3[7fb2b4819000+1f000]

We are running slapd 2.4.20, via this config:

include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema

pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args

disallow        bind_anon

loglevel        0
sizelimit       999999
idletimeout     10

modulepath      /usr/lib/ldap
moduleload      back_ldap
moduleload      back_hdb
moduleload      pcache

TLSCertificateFile      /etc/ldap/ssl/wildcard.crt
TLSCertificateKeyFile   /etc/ldap/ssl/wildcard.key
TLSCACertificateFile    /etc/ldap/ssl/wildcard.pem

database        ldap
uri             ldaps://
suffix          "ou=svcs,cn=auth"
rootdn          "uid=slapd,ou=svcs,cn=auth"

idassert-authzFrom "dn.subtree:ou=svcs,cn=auth"

### For some reason, we can no longer use indexes like we could in slapd 2.3 
### while using back_ldap (uncommenting these will present slapd from

#index           objectClass    eq
#index          uid,mail,cn     eq,sub
#index          queryid         eq

overlay                 pcache
proxycache              hdb 1000 1 50 1200
directory               "/var/lib/ldap"
proxycachequeries       100
proxyattrset            0 uid mail cn
proxytemplate           (uid=)  0 600

include                 /etc/ldap/acls.slapd


My hunch, given ITS #6452 (which I remarked was "solved"), is that id assertion
may cause slapd to crash when an identity tries to assert as itself?

e.g: uid=auth,ou=svcs,cn=auth >--idassert--> uid=auth,ou=svcs,cn=auth by means
of the idassert-authzFrom parameter, which authorizes the entire subtree in
which this account resides.  Again, just a hunch ...