Apart from some changes, I can't reproduce. See comments below. > 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]
This is not a useful bug report. You should rather follow instructions here <http://www.openldap.org/faq/data/cache/56.html> and provide useful information. A stack backtrace is essentially mandatory. Also, details about the DIT and the exact offending operations would be of help. > 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" I note that "cn=auth" should not be used, as this naming context is used internally for SASL identities. > 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 2.4 is pickier about syntax. "index" has no meaning within back-ldap. In 2.3 unrecognized keywords were plainly ignored. > 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 ... I had it working auth'ing both as idassert's "binddn" and as another user within the allowed subtree. Please improve the report and feed back. p.
