[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) (68.15.14.98)
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://192.168.1.1:636/
suffix "ou=svcs,cn=auth"
rootdn "uid=slapd,ou=svcs,cn=auth"
idassert-bind
bindmethod=simple
binddn="uid=auth,ou=svcs,cn=auth"
credentials="password"
mode=none
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
starting).
#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 ...
Thanks
J