openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6455) Able to crash slapd while using back_ldap
by quanah＠zimbra.com 19 Jan '10

19 Jan '10

--On Tuesday, January 19, 2010 2:02 AM +0000 j(a)gropefruit.com wrote: > I am currently in debug mode with slapd-dbg 2.4.20: > > Having run these commands: > > sudo gdb > handle SIGPIPE nostop=20 > handle SIGPIPE noprint > file /usr/sbin/slapd > set args -d -1 -u openldap -g openldap -h ldapi:/// ldaps:/// ldap:/// = > -f /etc/ldap/slapd.conf > run > > Once it crashes, I will be running: > > thr apply all bt > > After which I will upload the coredump to your FTP server. Just supply the backtrace for now, please. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 19 Jan '10

19 Jan '10

I am currently in debug mode with slapd-dbg 2.4.20: Having run these commands: sudo gdb handle SIGPIPE nostop=20 handle SIGPIPE noprint file /usr/sbin/slapd set args -d -1 -u openldap -g openldap -h ldapi:/// ldaps:/// ldap:/// = -f /etc/ldap/slapd.conf run Once it crashes, I will be running: thr apply all bt After which I will upload the coredump to your FTP server. J On Jan 18, 2010, at 00:58 , Hallvard B Furuseth wrote: > quanah(a)zimbra.com writes: >> Building unix software with debugging symbols is basic system >> administrator knowledge. There is nothing "openldap" specific about >> doing so. >=20 > Yes, there is, since OpenLDAP uses autoconf, libtool & co with = defaults > that get in the way of debugging: >=20 > Openldap 'make install' strips debugging symbols, so you must either = run > slapd from the source tree or install with 'make install STRIP=3D:' or > something, I don't remember at the moment. >=20 > Also it helps debugging to remove the optimize option which OpenLDAP > uses by default if it can compiler-specific, but with gcc that's > ./configure CFLAGS=3D"-g" >=20 >> I would suggest updating = <http://www.openldap.org/faq/data/cache/59.html>=20 >> with any information you feel specifically is lacking. >=20 > I'll make a note to update that one a bit. >=20 > --=20 > Hallvard

1 0

Re: (ITS#6457) hiding remote attribute with rwm-map in relay context crashes server
by masarati＠aero.polimi.it 18 Jan '10

18 Jan '10

> Full_Name: Guillaume Rousse > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.55.250.67) > > The following configuration is supposed to map remote 'homePhone' > attribute to > 'telephoneNumber', and hide remote 'telephoneNumber' attribute: > > database relay > suffix ou=telephony,dc=test > overlay rwm > rwm-suffixmassage ou=users,dc=test > > rwm-map attribute telephoneNumber homePhone > rwm-map attribute telephoneNumber > > However, the server crashes as soon as it has to handle an entry with a > telephoneNumber attribute, as demonstrated with the simple ldif below: > > dn: dc=test > dc: test > objectClass: top > objectClass: domain > > dn: ou=users,dc=test > ou: users > objectClass: top > objectClass: organizationalUnit > > dn: cn=user1,ou=users,dc=test > objectClass: inetOrgPerson > cn: user1 > sn: user1 > > dn: cn=user2,ou=users,dc=test > objectClass: inetOrgPerson > cn: user2 > sn: user2 > telephoneNumber: +33123456789 > > Here is the relevant part of server log, with debugLevel set to trace: > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, > <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: ==> limits_get: conn=1001 op=1 > self="[anonymous]" > this="ou=telephony,dc=test" > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=users,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=users,dc=test>, > <ou=users,dc=test> > Jan 18 13:29:58 slapd[12035]: => bdb_search > Jan 18 13:29:58 slapd[12035]: bdb_dn2entry("ou=users,dc=test") > Jan 18 13:29:58 slapd[12035]: search_candidates: base="ou=users,dc=test" > (0x00000002) scope=2 > Jan 18 13:29:58 slapd[12035]: => bdb_dn2idl("ou=users,dc=test") > Jan 18 13:29:58 slapd[12035]: <= bdb_dn2idl: id=3 first=2 last=4 > Jan 18 13:29:58 slapd[12035]: => bdb_presence_candidates (objectClass) > Jan 18 13:29:58 slapd[12035]: bdb_search_candidates: id=-1 first=2 last=4 > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, > <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 > dn="ou=telephony,dc=test" > Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: > <cn=user1,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: > <cn=user1,ou=telephony,dc=test>, <cn=user1,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 > dn="cn=user1,ou=telephony,dc=test" > Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: > <cn=user2,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: > <cn=user2,ou=telephony,dc=test>, <cn=user2,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="(null)" Could not reproduce. Apparently, it's something else that's creating hassle. Please provide a stack backtrace. p.

1 0

(ITS#6457) hiding remote attribute with rwm-map in relay context crashes server
by Guillaume.Rousse＠inria.fr 18 Jan '10

18 Jan '10

Full_Name: Guillaume Rousse Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.250.67) The following configuration is supposed to map remote 'homePhone' attribute to 'telephoneNumber', and hide remote 'telephoneNumber' attribute: database relay suffix ou=telephony,dc=test overlay rwm rwm-suffixmassage ou=users,dc=test rwm-map attribute telephoneNumber homePhone rwm-map attribute telephoneNumber However, the server crashes as soon as it has to handle an entry with a telephoneNumber attribute, as demonstrated with the simple ldif below: dn: dc=test dc: test objectClass: top objectClass: domain dn: ou=users,dc=test ou: users objectClass: top objectClass: organizationalUnit dn: cn=user1,ou=users,dc=test objectClass: inetOrgPerson cn: user1 sn: user1 dn: cn=user2,ou=users,dc=test objectClass: inetOrgPerson cn: user2 sn: user2 telephoneNumber: +33123456789 Here is the relevant part of server log, with debugLevel set to trace: Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: ==> limits_get: conn=1001 op=1 self="[anonymous]" this="ou=telephony,dc=test" Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=users,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=users,dc=test>, <ou=users,dc=test> Jan 18 13:29:58 slapd[12035]: => bdb_search Jan 18 13:29:58 slapd[12035]: bdb_dn2entry("ou=users,dc=test") Jan 18 13:29:58 slapd[12035]: search_candidates: base="ou=users,dc=test" (0x00000002) scope=2 Jan 18 13:29:58 slapd[12035]: => bdb_dn2idl("ou=users,dc=test") Jan 18 13:29:58 slapd[12035]: <= bdb_dn2idl: id=3 first=2 last=4 Jan 18 13:29:58 slapd[12035]: => bdb_presence_candidates (objectClass) Jan 18 13:29:58 slapd[12035]: bdb_search_candidates: id=-1 first=2 last=4 Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="ou=telephony,dc=test" Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <cn=user1,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <cn=user1,ou=telephony,dc=test>, <cn=user1,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="cn=user1,ou=telephony,dc=test" Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <cn=user2,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <cn=user2,ou=telephony,dc=test>, <cn=user2,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="(null)"

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by h.b.furuseth＠usit.uio.no 18 Jan '10

18 Jan '10

quanah(a)zimbra.com writes: > Building unix software with debugging symbols is basic system > administrator knowledge. There is nothing "openldap" specific about > doing so. Yes, there is, since OpenLDAP uses autoconf, libtool & co with defaults that get in the way of debugging: Openldap 'make install' strips debugging symbols, so you must either run slapd from the source tree or install with 'make install STRIP=:' or something, I don't remember at the moment. Also it helps debugging to remove the optimize option which OpenLDAP uses by default if it can compiler-specific, but with gcc that's ./configure CFLAGS="-g" > I would suggest updating <http://www.openldap.org/faq/data/cache/59.html> > with any information you feel specifically is lacking. I'll make a note to update that one a bit. -- Hallvard

1 0

(ITS#6456) Feature Request
by j＠gropefruit.com 18 Jan '10

18 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian-Lenny/amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Greetings, Having found out this doesn't already exist as another parameter or configuration method, I am hereby submitting a request for a particular feature. When performing idassert-bind operations, such as with back_ldap, it would be great if an option could be added which would allow specific matched client DNs to be matched and asserted as usual (e.g: the anonymous user asserting to a backend "proxyauthenticator" account) .... while other clients (flagged somehow) would pass-through as themselves. Example (as I might do it for my purposes): idassert-bind bindmethod="simple" binddn="uid=proxyauthenticator,ou=users,dc=example,dc=com" credentials="password_string" starttls="yes" tls_reqcert="never" mode="none" # anonymous clients will assert as "proxyauthenticator", since the backend may not allow anonymous binds. idassert-authzFrom "dn.exact:" # this guy will pass through as himself to the backend, as-is. idassert-passThrough "dn.exact:uid=admin,ou=users,dc=example,dc=com" This would be really helpful, not sure if its difficult to implement ...

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by quanah＠zimbra.com 17 Jan '10

17 Jan '10

--On Sunday, January 17, 2010 10:28 PM +0000 j(a)gropefruit.com wrote: > In general, a page should exist on openldap.org that details, in full, = > the debugging/core dump process and best practices.=20 Building unix software with debugging symbols is basic system administrator knowledge. There is nothing "openldap" specific about doing so. Same with debugging the core files that are generated. Here's a page on basic C compilation: <http://www.cs.rutgers.edu/LCSR-Computing/programming.html> Most specifically, note the "-g" option to CFLAGS, which instructs gcc, in this case, to include debugging symbols in the resulting compiled code. Ensure that when you install, you set STRIP="" so that the "make" program does not strip out the debugging symbols on installation. Run the new slapd that has the debugging information and get a core file. Use GDB to get a backtrace from it. Again, nothing here is specific to OpenLDAP, which is why there is no "OpenLDAP" page on how to do this. I will note the FAQ is fully interactive, allowing anyone to create an entry, if you feel so inclined. I would suggest updating <http://www.openldap.org/faq/data/cache/59.html> with any information you feel specifically is lacking. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 17 Jan '10

17 Jan '10

--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(a)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(a)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.  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.  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?  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.  You should = rather follow instructions<br>here <<a = href=3D"http://www.openldap.org/faq/data/cache/56.html">http://www.openlda= p.org/faq/data/cache/56.html</a>> and provide useful<br>information. =  A stack backtrace is essentially mandatory.  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 =         /etc/ldap/schema/core.sche= ma<br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/cosine.sc= hema<br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/nis.schem= a<br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/inetorgpe= rson.schema<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">pidfile =         /var/run/slapd/slapd.pid<b= r></blockquote><blockquote type=3D"cite">argsfile =        /var/run/slapd/slapd.args<br></b= lockquote><blockquote type=3D"cite"><br></blockquote><blockquote = type=3D"cite">disallow =        bind_anon<br></blockquote><block= quote type=3D"cite"><br></blockquote><blockquote type=3D"cite">loglevel =        0<br></blockquote><blockquote = type=3D"cite">sizelimit =       999999<br></blockquote><blockquote = type=3D"cite">idletimeout =     10<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">modulepath =      /usr/lib/ldap<br></blockquote><blockquote = type=3D"cite">moduleload =      back_ldap<br></blockquote><blockquote = type=3D"cite">moduleload =      back_hdb<br></blockquote><blockquote = type=3D"cite">moduleload =      pcache<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">TLSCertificateFile =      /etc/ldap/ssl/wildcard.crt<br></blockquote><= blockquote type=3D"cite">TLSCertificateKeyFile =   /etc/ldap/ssl/wildcard.key<br></blockquote><blockquote = type=3D"cite">TLSCACertificateFile =    /etc/ldap/ssl/wildcard.pem<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">database =        ldap<br></blockquote><blockquote= type=3D"cite">uri =             <a= = href=3D"ldaps://192.168.1.1:636/">ldaps://192.168.1.1:636/</a><br></blockq= uote><blockquote type=3D"cite">suffix =          "ou=3Dsvcs,cn=3Dauth= "<br></blockquote><blockquote type=3D"cite">rootdn =          "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).  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"> =   bindmethod=3Dsimple<br></blockquote><blockquote type=3D"cite">= =   binddn=3D"uid=3Dauth,ou=3Dsvcs,cn=3Dauth"<br></blockquote><blo= ckquote type=3D"cite"> =   credentials=3D"password"<br></blockquote><blockquote = type=3D"cite">   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 =           objectClass =    eq<br></blockquote><blockquote type=3D"cite">#index =          uid,mail,cn =     eq,sub<br></blockquote><blockquote = type=3D"cite">#index =          queryid =         eq<br></blockquote><br></d= iv></blockquote><div><br></div><div>Thanks.  This is useful to = know.</div><br><blockquote type=3D"cite"><div>2.4 is pickier about = syntax.  "index" has no meaning within back-ldap.  In<br>2.3 = unrecognized keywords were plainly ignored.<br><br><blockquote = type=3D"cite">overlay =             &n= bsp;   pcache<br></blockquote><blockquote = type=3D"cite">proxycache =             &n= bsp;hdb 1000 1 50 1200<br></blockquote><blockquote type=3D"cite">directory= =             &n= bsp; "/var/lib/ldap"<br></blockquote><blockquote = type=3D"cite">proxycachequeries =       100<br></blockquote><blockquote = type=3D"cite">proxyattrset =            0 uid = mail cn<br></blockquote><blockquote type=3D"cite">proxytemplate =           (uid=3D) =  0 600<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">include =             &n= bsp;   /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 >--idassert--> = 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.  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. </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--

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by masarati＠aero.polimi.it 17 Jan '10

17 Jan '10

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.

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 16 Jan '10

16 Jan '10

And just for the record, this exact config (the only difference being = the index params were uncommented) was working fine on Debian Etch / = slapd 2.3.x, which we have been using for a very long time, with no ill = effects (certainly nothing like this). We only rebuilt this same box = today with 2.4.20 on Lenny/Amd64. J=

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs