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

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



--Apple-Mail-1--155291042
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

See my inline changes:

On Jan 17, 2010, at 14:13 , masarati@aero.polimi.it wrote:

> Apart from some changes, I can't reproduce.  See comments below.
>=20
>> Full_Name: J
>> Version: 2.4.20
>> OS: Debian-Lenny/amd64
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (68.15.14.98)
>>=20
>>=20
>> Host running Debian Lenny amd64 is experiencing a strange issue.  =
slapd is
>> segfaulting for no obvious reason. Syslog output:
>>=20
>> 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]
>=20
Is there a recommended debugging "practice" you guys recommend? And what =
control do I have over the details of our DIT being produced in the core =
dump?  Security concerns on part of my organization may prevent such a =
backtrace ... =3D(

> 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.
>=20
>> We are running slapd 2.4.20, via this config:
>>=20
>> include         /etc/ldap/schema/core.schema
>> include         /etc/ldap/schema/cosine.schema
>> include         /etc/ldap/schema/nis.schema
>> include         /etc/ldap/schema/inetorgperson.schema
>>=20
>> pidfile         /var/run/slapd/slapd.pid
>> argsfile        /var/run/slapd/slapd.args
>>=20
>> disallow        bind_anon
>>=20
>> loglevel        0
>> sizelimit       999999
>> idletimeout     10
>>=20
>> modulepath      /usr/lib/ldap
>> moduleload      back_ldap
>> moduleload      back_hdb
>> moduleload      pcache
>>=20
>> TLSCertificateFile      /etc/ldap/ssl/wildcard.crt
>> TLSCertificateKeyFile   /etc/ldap/ssl/wildcard.key
>> TLSCACertificateFile    /etc/ldap/ssl/wildcard.pem
>>=20
>> database        ldap
>> uri             ldaps://192.168.1.1:636/
>> suffix          "ou=3Dsvcs,cn=3Dauth"
>> rootdn          "uid=3Dslapd,ou=3Dsvcs,cn=3Dauth"
>=20

I lied. Our syntax is not cn=3Dauth, I had to sanitize it from what it =
really was (security concerns for my company).  But thanks for the note.

> I note that "cn=3Dauth" should not be used, as this naming context is =
used
> internally for SASL identities.
>=20
>> idassert-bind
>>   bindmethod=3Dsimple
>>   binddn=3D"uid=3Dauth,ou=3Dsvcs,cn=3Dauth"
>>   credentials=3D"password"
>>   mode=3Dnone
>> idassert-authz=46rom "dn.subtree:ou=3Dsvcs,cn=3Dauth"
>>=20
>> ### 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).
>>=20
>> #index           objectClass    eq
>> #index          uid,mail,cn     eq,sub
>> #index          queryid         eq
>=20

Thanks.  This is useful to know.

> 2.4 is pickier about syntax.  "index" has no meaning within back-ldap. =
 In
> 2.3 unrecognized keywords were plainly ignored.
>=20
>> overlay                 pcache
>> proxycache              hdb 1000 1 50 1200
>> directory               "/var/lib/ldap"
>> proxycachequeries       100
>> proxyattrset            0 uid mail cn
>> proxytemplate           (uid=3D)  0 600
>>=20
>> include                 /etc/ldap/acls.slapd
>>=20
>> ##########
>>=20
>>=20
>> 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?
>>=20
>> e.g: uid=3Dauth,ou=3Dsvcs,cn=3Dauth >--idassert--> =
uid=3Dauth,ou=3Dsvcs,cn=3Dauth by
>> means
>> of the idassert-authz=46rom parameter, which authorizes the entire =
subtree
>> in
>> which this account resides.  Again, just a hunch ...
>=20
> I had it working auth'ing both as idassert's "binddn" and as another =
user
> within the allowed subtree.
>=20

In general, a page should exist on openldap.org that details, in full, =
the debugging/core dump process and best practices.=20

> Please improve the report and feed back.
>=20
> p.
>=20


--Apple-Mail-1--155291042
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">See =
my inline changes:<div><br></div><div><div><div>On Jan 17, 2010, at =
14:13 , <a =
href=3D"mailto:masarati@aero.polimi.it";>masarati@aero.polimi.it</a> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Apart from some changes, I can't reproduce. &nbsp;See =
comments below.<br><br><blockquote type=3D"cite">Full_Name: =
J<br></blockquote><blockquote type=3D"cite">Version: =
2.4.20<br></blockquote><blockquote type=3D"cite">OS: =
Debian-Lenny/amd64<br></blockquote><blockquote type=3D"cite">URL: <a =
href=3D"ftp://ftp.openldap.org/incoming/";>ftp://ftp.openldap.org/incoming/=
</a><br></blockquote><blockquote type=3D"cite">Submission from: (NULL) =
(68.15.14.98)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Host running =
Debian Lenny amd64 is experiencing a strange issue. &nbsp;slapd =
is<br></blockquote><blockquote type=3D"cite">segfaulting for no obvious =
reason. Syslog output:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Jan 15 19:29:59 =
ldapc1 kernel: [10702.262741] slapd[3218]: segfault at =
40<br></blockquote><blockquote =
type=3D"cite">ip<br></blockquote><blockquote type=3D"cite">7fb2b4829875 =
sp 44d90940 error 4 in<br></blockquote><blockquote =
type=3D"cite">back_ldap-2.4.so.2.5.3[7fb2b4819000+1f000]<br></blockquote><=
br></div></blockquote><div>Is there a recommended debugging "practice" =
you guys recommend? And what control do I have over the details of our =
DIT being produced in the core dump? &nbsp;Security concerns on part of =
my organization may prevent such a backtrace ... =3D(</div><br><blockquote=
 type=3D"cite"><div>This is not a useful bug report. &nbsp;You should =
rather follow instructions<br>here &lt;<a =
href=3D"http://www.openldap.org/faq/data/cache/56.html";>http://www.openlda=
p.org/faq/data/cache/56.html</a>&gt; and provide useful<br>information. =
&nbsp;A stack backtrace is essentially mandatory. &nbsp;Also, =
details<br>about the DIT and the exact offending operations would be of =
help.<br><br><blockquote type=3D"cite">We are running slapd 2.4.20, via =
this config:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">include =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/etc/ldap/schema/core.sche=
ma<br></blockquote><blockquote type=3D"cite">include =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/etc/ldap/schema/cosine.sc=
hema<br></blockquote><blockquote type=3D"cite">include =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/etc/ldap/schema/nis.schem=
a<br></blockquote><blockquote type=3D"cite">include =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/etc/ldap/schema/inetorgpe=
rson.schema<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">pidfile =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/var/run/slapd/slapd.pid<b=
r></blockquote><blockquote type=3D"cite">argsfile =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/var/run/slapd/slapd.args<br></b=
lockquote><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">disallow =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bind_anon<br></blockquote><block=
quote type=3D"cite"><br></blockquote><blockquote type=3D"cite">loglevel =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0<br></blockquote><blockquote =
type=3D"cite">sizelimit =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;999999<br></blockquote><blockquote =
type=3D"cite">idletimeout =
&nbsp;&nbsp;&nbsp;&nbsp;10<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">modulepath =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/usr/lib/ldap<br></blockquote><blockquote =
type=3D"cite">moduleload =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;back_ldap<br></blockquote><blockquote =
type=3D"cite">moduleload =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;back_hdb<br></blockquote><blockquote =
type=3D"cite">moduleload =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;pcache<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">TLSCertificateFile =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/etc/ldap/ssl/wildcard.crt<br></blockquote><=
blockquote type=3D"cite">TLSCertificateKeyFile =
&nbsp;&nbsp;/etc/ldap/ssl/wildcard.key<br></blockquote><blockquote =
type=3D"cite">TLSCACertificateFile =
&nbsp;&nbsp;&nbsp;/etc/ldap/ssl/wildcard.pem<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">database =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ldap<br></blockquote><blockquote=
 type=3D"cite">uri =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a=
 =
href=3D"ldaps://192.168.1.1:636/">ldaps://192.168.1.1:636/</a><br></blockq=
uote><blockquote type=3D"cite">suffix =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"ou=3Dsvcs,cn=3Dauth=
"<br></blockquote><blockquote type=3D"cite">rootdn =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"uid=3Dslapd,ou=3Dsv=
cs,cn=3Dauth"<br></blockquote><br></div></blockquote><div><br></div><div>I=
 lied. Our syntax is not cn=3Dauth, I had to sanitize it from what it =
really was (security concerns for my company). &nbsp;But thanks for the =
note.</div><br><blockquote type=3D"cite"><div>I note that "cn=3Dauth" =
should not be used, as this naming context is used<br>internally for =
SASL identities.<br><br><blockquote =
type=3D"cite">idassert-bind<br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;bindmethod=3Dsimple<br></blockquote><blockquote type=3D"cite">=
 =
&nbsp;&nbsp;binddn=3D"uid=3Dauth,ou=3Dsvcs,cn=3Dauth"<br></blockquote><blo=
ckquote type=3D"cite"> =
&nbsp;&nbsp;credentials=3D"password"<br></blockquote><blockquote =
type=3D"cite"> &nbsp;&nbsp;mode=3Dnone<br></blockquote><blockquote =
type=3D"cite">idassert-authz=46rom =
"dn.subtree:ou=3Dsvcs,cn=3Dauth"<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">### For some =
reason, we can no longer use indexes like we could in =
slapd<br></blockquote><blockquote =
type=3D"cite">2.3<br></blockquote><blockquote type=3D"cite">### while =
using back_ldap (uncommenting these will present slapd =
from<br></blockquote><blockquote =
type=3D"cite">starting).<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#index =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;objectClass =
&nbsp;&nbsp;&nbsp;eq<br></blockquote><blockquote type=3D"cite">#index =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uid,mail,cn =
&nbsp;&nbsp;&nbsp;&nbsp;eq,sub<br></blockquote><blockquote =
type=3D"cite">#index =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;queryid =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;eq<br></blockquote><br></d=
iv></blockquote><div><br></div><div>Thanks. &nbsp;This is useful to =
know.</div><br><blockquote type=3D"cite"><div>2.4 is pickier about =
syntax. &nbsp;"index" has no meaning within back-ldap. &nbsp;In<br>2.3 =
unrecognized keywords were plainly ignored.<br><br><blockquote =
type=3D"cite">overlay =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;pcache<br></blockquote><blockquote =
type=3D"cite">proxycache =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;hdb 1000 1 50 1200<br></blockquote><blockquote type=3D"cite">directory=
 =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;"/var/lib/ldap"<br></blockquote><blockquote =
type=3D"cite">proxycachequeries =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;100<br></blockquote><blockquote =
type=3D"cite">proxyattrset =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0 uid =
mail cn<br></blockquote><blockquote type=3D"cite">proxytemplate =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(uid=3D) =
&nbsp;0 600<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">include =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;/etc/ldap/acls.slapd<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">##########<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">My hunch, given =
ITS #6452 (which I remarked was "solved"), is that =
id<br></blockquote><blockquote =
type=3D"cite">assertion<br></blockquote><blockquote type=3D"cite">may =
cause slapd to crash when an identity tries to assert as =
itself?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">e.g: =
uid=3Dauth,ou=3Dsvcs,cn=3Dauth &gt;--idassert--&gt; =
uid=3Dauth,ou=3Dsvcs,cn=3Dauth by<br></blockquote><blockquote =
type=3D"cite">means<br></blockquote><blockquote type=3D"cite">of the =
idassert-authz=46rom parameter, which authorizes the entire =
subtree<br></blockquote><blockquote =
type=3D"cite">in<br></blockquote><blockquote type=3D"cite">which this =
account resides. &nbsp;Again, just a hunch =
...<br></blockquote><br></div></blockquote><blockquote =
type=3D"cite"><div>I had it working auth'ing both as idassert's "binddn" =
and as another user<br>within the allowed =
subtree.<br><br></div></blockquote><div><br></div><div>In general, a =
page should exist on <a href=3D"http://openldap.org";>openldap.org</a> =
that details, in full, the debugging/core dump process and best =
practices.&nbsp;</div><div><br></div><blockquote type=3D"cite"><div>Please=
 improve the report and feed back.<br><font class=3D"Apple-style-span" =
color=3D"#000000"><font class=3D"Apple-style-span" =
color=3D"#144FAE"><br></font></font></div></blockquote><blockquote =
type=3D"cite"><div>p.<br><br></div></blockquote></div><br></div></body></h=
tml>=

--Apple-Mail-1--155291042--