- openldap-bugs - openldap.org

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

12 Feb '10

I am unable to reproduce this error. My peers and I believe this may = have been something unrelated to slapd specifically. You may close. Sorry.

1 0

(ITS#6470) slapd dying under load
by bmaupin＠uta.edu 10 Feb '10

10 Feb '10

Full_Name: Bryan Maupin Version: 2.4.21 OS: Red Hat Enterprise Linux 5.4 URL: http://omega.uta.edu/~bmaupin/bryan-maupin-100210.txt Submission from: (NULL) (129.107.38.77) About 2 months ago we upgraded from OpenLDAP 2.3 to OpenLDAP 2.4.19. All seemed well for about 4 weeks, and then slapd started dying on our replica servers. It frequently correlates with a CPU load spike, but not always. Available memory doesn't seem to be an issue. These problems didn't show up during testing, and don't seem to have affected the master, which has been running without stopping for the last 2 months, so the problems only seem to manifest themselves under production load. In our /var/log/messages we get messages like: Jan 15 16:58:03 kernel: slapd[22663] general protection rip:2ac667af65cc rsp:4659d970 error:0 Jan 16 15:42:34 kernel: slapd[10272] general protection rip:2b71f6c6d9c4 rsp:45441980 error:0 Jan 16 17:20:01 kernel: slapd[7538] general protection rip:2aec51954ae0 rsp:449518d0 error:0 Jan 19 13:38:46 kernel: slapd[2821] general protection rip:2aeac3070ae0 rsp:4918f8d0 error:0 Quanah Gibson-Mount told me to upgrade OpenLDAP and tcmalloc, so I did, but it didn't fix the problem. We're running OpenLDAP 2.4.21 on RHEL 5.4, with Heimdal 1.2.1-3, OpenSSL 0.9.8k, Cyrus-SASL 2.1.23, BDB 4.7.25 (with patches), Google tcmalloc (minimal) 1.5. Backtrace is available here: http://omega.uta.edu/~bmaupin/bryan-maupin-100210.txt Thanks.

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by apm＠mutex.dk 06 Feb '10

06 Feb '10

Howard Chu wrote: >> If I can't trust slapcat during this >> phase, how can I trust slapcat for backups? > > Does slapcat behave this way on the active server? Yes. Sorry for the delay, but I've only just confirmed it now. The passive server needed to be moved, so I took it completely offline. Now there's only the active server and a backup shows the same result. Running slapcat while slapd is running produced invalid LDIF. Running slapcat after slapd is stopped produced OK LDIF - at least once. slapd has since been upgraded to 2.4.21. /Peter

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by gerard.ranke＠kmt.hku.nl 05 Feb '10

05 Feb '10

Problem solved! olcSyncrepl now reads: olcSyncrepl: rid=001 provider=ldap://masterldap.example.com:389 bindmethod=simple timeout =0 network-timeout=0 binddn="cn=dsyncuser,dc=example,dc=com" credentials="xxxxxxx " starttls=critical tls_cert="/usr/ssl/certs/examplewildcard.cert" tl s_key="/usr/ssl/certs/examplewildcard.key" tls_cacert="/usr/ ssl/certs/cacert_root.crt" tls_reqcert=demand tls_crlcheck=none filter="(obje ctClass=*)" searchbase="dc=example,dc=com" scope=sub attrs="*,+" schemachecking=of f type=refreshAndPersist retry="5 5 10 +" so the 'uri=""' string is no longer present, and slapd starts normally after converting. Thanks for the quick fix! Best, gerard

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by rhafer＠suse.de 03 Feb '10

03 Feb '10

Am Mittwoch 03 Februar 2010 13:10:04 schrieb gerard.ranke(a)kmt.hku.nl: > Hi Ralf, > > Ralf Haferkamp wrote: > > A fix is in HEAD now (servers/slapd/config.c rev 1.513) please test. > > I'm afraid I need a little guidance here. To test the fix, I replaced > the config.c from 2.4.21 with rev 1.513, but I got the errors below. > I'm guessing I'm being naive to think this would work, and that I > need to d'l the complete HEAD to compile, but how would I do that? Either that. Or you could get the diff from 1.512 to 1.153 from cvs and apply that on your 2.4.21 tree. > Cvs needs a module name, and I tried 'HEAD' and > 'OPENLDAP_REL_ENG_2_4' but these names couldn't be found. I couldn't > find anything else in the devel faq and website that seems like a > candidate for a module name, so could you please give me some > pointers? You can find instruction howto checkout OpenLDAP from cvs here: http://www.openldap.org/software/repo.html#AnonCVS Further up on that page you will also find a table listing valid modules (you want "ldap"). -- Ralf

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by gerard.ranke＠kmt.hku.nl 03 Feb '10

03 Feb '10

Hi Ralf, Ralf Haferkamp wrote: > A fix is in HEAD now (servers/slapd/config.c rev 1.513) please test. I'm afraid I need a little guidance here. To test the fix, I replaced the config.c from 2.4.21 with rev 1.513, but I got the errors below. I'm guessing I'm being naive to think this would work, and that I need to d'l the complete HEAD to compile, but how would I do that? Cvs needs a module name, and I tried 'HEAD' and 'OPENLDAP_REL_ENG_2_4' but these names couldn't be found. I couldn't find anything else in the devel faq and website that seems like a candidate for a module name, so could you please give me some pointers? Many thanks in advance, gerard cc-1020 c99: ERROR File = config.c, Line = 1222 The identifier "slap_keepalive" is undefined. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1020 c99: ERROR File = config.c, Line = 1222 The identifier "sk" is undefined. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1029 c99: ERROR File = config.c, Line = 1222 An expression is expected at this point. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1065 c99: ERROR File = config.c, Line = 1222 A semicolon is expected at this point. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1020 c99: ERROR File = config.c, Line = 1238 The identifier "slap_keepalive" is undefined. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1020 c99: ERROR File = config.c, Line = 1238 The identifier "sk" is undefined. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1029 c99: ERROR File = config.c, Line = 1238 An expression is expected at this point. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1065 c99: ERROR File = config.c, Line = 1238 A semicolon is expected at this point. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1065 c99: ERROR File = config.c, Line = 1239 A semicolon is expected at this point. slap_keepalive sk2; ^ cc-1020 c99: ERROR File = config.c, Line = 1242 The identifier "sk2" is undefined. sk2.sk_idle = 0; ^ cc-1020 c99: ERROR File = config.c, Line = 1246 The identifier "sk2" is undefined. sk2.sk_idle = strtol( s, &next, 10 ); ^ cc-1020 c99: ERROR File = config.c, Line = 1259 The identifier "sk2" is undefined. sk2.sk_probes = 0; ^ cc-1020 c99: ERROR File = config.c, Line = 1263 The identifier "sk2" is undefined. sk2.sk_probes = strtol( s, &next, 10 ); ^ cc-1020 c99: ERROR File = config.c, Line = 1276 The identifier "sk2" is undefined. sk2.sk_interval = 0; ^ cc-1020 c99: ERROR File = config.c, Line = 1280 The identifier "sk2" is undefined. sk2.sk_interval = strtol( s, &next, 10 ); ^ cc-1020 c99: ERROR File = config.c, Line = 1290 The identifier "sk2" is undefined. *sk = sk2; ^ cc-1565 c99: ERROR File = config.c, Line = 1336 The struct "slap_bindconf" has no field "sb_keepalive". { BER_BVC("keepalive="), offsetof(slap_bindconf, sb_keepalive), 'x', 0, (slap_verbmasks *)slap_keepalive_parse }, ^ ( warnings skipped... ) cc-1565 c99: ERROR File = config.c, Line = 1889 The struct "slap_bindconf" has no field "sb_keepalive". if ( sb->sb_keepalive.sk_idle ) { ^ cc-1565 c99: ERROR File = config.c, Line = 1890 The struct "slap_bindconf" has no field "sb_keepalive". ldap_set_option( ld, LDAP_OPT_X_KEEPALIVE_IDLE, &sb->sb_keepalive.sk_idle ); ^ cc-1565 c99: ERROR File = config.c, Line = 1893 The struct "slap_bindconf" has no field "sb_keepalive". if ( sb->sb_keepalive.sk_probes ) { ^ cc-1565 c99: ERROR File = config.c, Line = 1894 The struct "slap_bindconf" has no field "sb_keepalive". ldap_set_option( ld, LDAP_OPT_X_KEEPALIVE_PROBES, &sb->sb_keepalive.sk_probes ); ^ cc-1565 c99: ERROR File = config.c, Line = 1897 The struct "slap_bindconf" has no field "sb_keepalive". if ( sb->sb_keepalive.sk_interval ) { ^ cc-1565 c99: ERROR File = config.c, Line = 1898 The struct "slap_bindconf" has no field "sb_keepalive". ldap_set_option( ld, LDAP_OPT_X_KEEPALIVE_INTERVAL, &sb->sb_keepalive.sk_interval );

1 0

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by rhafer＠suse.de 03 Feb '10

03 Feb '10

Am Mittwoch 03 Februar 2010 09:39:19 schrieb hyc(a)symas.com: > rhafer(a)suse.de wrote: > > Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc(a)symas.com: > >> But how did the suffix entry get created without an entryCSN in the > >> first place? The MOD that updates the contextCSN doesn't happen > >> until after the suffix entry already exists. > > > > It wasn't created without an entryCSN. It always had one. But the > > MOD to update the contextCSN (coming from the provider) doesn't > > contain one. So bdb_modify() will call slap_mods_opattrs() to add > > entryCSN to the MOD operation. The easiest fix is probably to never > > touch the opattrs if "updatedn" is doing MODs, though I am not yet > > sure if it might break something. Currently my fix (not committed > > yet) only skips the slap_mods_opattrs() step if "updatedn" it is > > doing a MOD on contextCSN. > > Ah, got it. Yes, sounds like your fix is fine. Do you think it's fine to always skip slap_mods_opattrs() if "updatedn" is writing? Or should I check for contextCSN MODs specifically? > Historically the updatedn user (e.g. slurpd) has always provided all of > the operational attributes in its updates. -- Ralf

1 0

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by hyc＠symas.com 03 Feb '10

03 Feb '10

rhafer(a)suse.de wrote: > Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc(a)symas.com: >> But how did the suffix entry get created without an entryCSN in the >> first place? The MOD that updates the contextCSN doesn't happen until >> after the suffix entry already exists. > It wasn't created without an entryCSN. It always had one. But the MOD to > update the contextCSN (coming from the provider) doesn't contain one. So > bdb_modify() will call slap_mods_opattrs() to add entryCSN to the MOD > operation. The easiest fix is probably to never touch the opattrs if > "updatedn" is doing MODs, though I am not yet sure if it might break > something. Currently my fix (not committed yet) only skips the > slap_mods_opattrs() step if "updatedn" it is doing a MOD on contextCSN. Ah, got it. Yes, sounds like your fix is fine. Historically the updatedn user (e.g. slurpd) has always provided all of the operational attributes in its updates. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by rhafer＠suse.de 03 Feb '10

03 Feb '10

Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc(a)symas.com: > ralf(a)OpenLDAP.org wrote: > > Full_Name: Ralf Haferkamp > > Version: RE24, HEAD > > OS: > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (89.166.208.247) > > Submitted by: ralf > > > > > > When using push-based replication (syncrepl-proxy) the entryCSN of > > the consumer's server's suffix entry (the one that also holds the > > contextCSN Attribute) is not in sync with the value on the > > provider. (Other operational Attributes are out of sync as well) > > > > This is because the MOD Operation to update the contextCSN (sent by > > the provider) does not contain any other operational Attributes. > > That causes the consumer to add those attributes itself. > > > > I guess the problem is mostly cosmetic, but I'll submit a fix > > anyway. (not calling slap_mods_opattrs() if the updatedn modifies > > "contextCSN") > > But how did the suffix entry get created without an entryCSN in the > first place? The MOD that updates the contextCSN doesn't happen until > after the suffix entry already exists. It wasn't created without an entryCSN. It always had one. But the MOD to update the contextCSN (coming from the provider) doesn't contain one. So bdb_modify() will call slap_mods_opattrs() to add entryCSN to the MOD operation. The easiest fix is probably to never touch the opattrs if "updatedn" is doing MODs, though I am not yet sure if it might break something. Currently my fix (not committed yet) only skips the slap_mods_opattrs() step if "updatedn" it is doing a MOD on contextCSN. -- Ralf

1 0

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by hyc＠symas.com 02 Feb '10

02 Feb '10

ralf(a)OpenLDAP.org wrote: > Full_Name: Ralf Haferkamp > Version: RE24, HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.208.247) > Submitted by: ralf > > > When using push-based replication (syncrepl-proxy) the entryCSN of the > consumer's server's suffix entry (the one that also holds the contextCSN > Attribute) is not in sync with the value on the provider. (Other operational > Attributes are out of sync as well) > > This is because the MOD Operation to update the contextCSN (sent by the > provider) does not contain any other operational Attributes. That causes the > consumer to add those attributes itself. > > I guess the problem is mostly cosmetic, but I'll submit a fix anyway. (not > calling slap_mods_opattrs() if the updatedn modifies "contextCSN") > But how did the suffix entry get created without an entryCSN in the first place? The MOD that updates the contextCSN doesn't happen until after the suffix entry already exists. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 02 Feb '10

02 Feb '10

New and improved patch, to address issues mentioned by Howard, and to clean up some memory leaks. ftp://ftp.openldap.org/incoming/openldap-2.4.21-tls_m_c-InitContext-PEM-201… Note: This new version depends on Mozilla NSS 3.12.6 (currently unreleased) and currently unreleased patches of PEM NSS in order to avoid a couple of memory leaks.

1 0

(ITS#6469) push replication entryCSN of database suffix out of sync
by ralf＠OpenLDAP.org 02 Feb '10

02 Feb '10

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.208.247) Submitted by: ralf When using push-based replication (syncrepl-proxy) the entryCSN of the consumer's server's suffix entry (the one that also holds the contextCSN Attribute) is not in sync with the value on the provider. (Other operational Attributes are out of sync as well) This is because the MOD Operation to update the contextCSN (sent by the provider) does not contain any other operational Attributes. That causes the consumer to add those attributes itself. I guess the problem is mostly cosmetic, but I'll submit a fix anyway. (not calling slap_mods_opattrs() if the updatedn modifies "contextCSN")

1 0

Re: (ITS#6468) ACLs in subordinate databases can be ignored
by rein＠OpenLDAP.org 02 Feb '10

02 Feb '10

On 02/02/2010 04:25 PM, Hallvard B Furuseth wrote: > Hold on. Is the current behavior self-consistent, i.e. one could call > it an undocumented feature? If so someone may have noticed this and > written their ACLs accordingly. It's not friendly to change the > meaning of existing installations' ACLs in the middle of RE24. > > OTOH if current behavior is broken even as a "feature", fix away. > E.g. if clients can choose which ACLs will apply in the subordinate > by picking a base DN inside vs outside the subordinate. From my analyzis of the problem, the subordinate ACLs are used in all cases except when syncprov desides which "live" modifications it should replicate to its consumers. Searching with the credentials used by the syncrepl consumer gives me the attributes and entries my subordinate ACLs allows, and they are replicated during the refresh phase. But access to entries and/or attributes being modified during the persistent phase are rejected. But yes, the change should be analyzed by somebody else before being included in a release. Rein

1 0

Re: (ITS#6468) ACLs in subordinate databases can be ignored
by h.b.furuseth＠usit.uio.no 02 Feb '10

02 Feb '10

Hold on. Is the current behavior self-consistent, i.e. one could call it an undocumented feature? If so someone may have noticed this and written their ACLs accordingly. It's not friendly to change the meaning of existing installations' ACLs in the middle of RE24. OTOH if current behavior is broken even as a "feature", fix away. E.g. if clients can choose which ACLs will apply in the subordinate by picking a base DN inside vs outside the subordinate. -- Hallvard

1 0

(ITS#6468) ACLs in subordinate databases can be ignored
by rein＠OpenLDAP.org 02 Feb '10

02 Feb '10

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) Submitted by: rein In a glued database configuration where overlays (syncprov, accesslog) are stacked on top of the glue overlay, ACL evaluation initiated from these overlays can be evaluated by the superior glue database and not the subordinate database where the entry actually exist. I.e, ACLs defined in the subordinate databases are ignored in these cases. A fix that implements bi_access_allowed in the glue overlay is coming, it delegates the call to the actual backend where the entry being referenced exist. An alternative approach I considered was to require the overlays to call select_backend() to find the actual backend where the entry exist, but that would imo obfuscate the modularization of the code. -- Rein Tollevik Basefarm AS

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by gerard.ranke＠kmt.hku.nl 02 Feb '10

02 Feb '10

Ralf Haferkamp wrote: > A fix is in HEAD now (servers/slapd/config.c rev 1.513) please test. Thanks! Hopefully I can compile & test tomorrow, I'll let you know. Best, gerard

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by Ralf Haferkamp 02 Feb '10

02 Feb '10

A fix is in HEAD now (servers/slapd/config.c rev 1.513) please test.

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by Ralf Haferkamp 02 Feb '10

02 Feb '10

This got introduced by the fix for ITS#6419. I am currently working on a fix.

1 0

(ITS#6467) syncrepl enhancements
by hyc＠OpenLDAP.org 02 Feb '10

02 Feb '10

Full_Name: Howard Chu Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.212) Submitted by: hyc Syncrepl refreshes can be very expensive without a sessionlog, and the syncprov sessionlog is inadequate because it's in-memory only, and doesn't survive a restart. Syncprov should be extended to take advantage of the accesslog overlay if it is available.

1 0

Re: (ITS#6464) Buffer overflow
by csdr＠lthd.com 01 Feb '10

01 Feb '10

Sorry. I hope this helps: http://lthd.com/slapd.out On 01/31/2010 01:05 AM, Howard Chu wrote: > csdr(a)lthd.com wrote: >> Full_Name: Chis-Serban Dinu-Razvan >> Version: 2.4.21 >> OS: Fedora 12 >> URL: http://lthd.com/out1.txt >> Submission from: (NULL) (193.231.233.40) >> >> >> I have a master ldap server running openldap 2.4.21 and 3 replicas >> running >> 2.4.15 and 2.4.19 and I when I try to delete/rename an object, the >> master dies >> with an buffer overflow error. I mention that before the master was >> 2.4.15 and >> the replica running 2.4.19 died. I have updated the master to 2.4.19 >> and it >> start dyeing. Then I upgraded it to 2.4.21 an it still dies. It dies >> even if the >> syncprov is off. >> > Please provide a stack trace from this crash. Be sure to compile with > debug symbols enabled and no optimization, otherwise we won't be able > to track anything down. >

1 0

Re: (ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by masarati＠aero.polimi.it 01 Feb '10

01 Feb '10

hyc(a)symas.com wrote: >> BTW, what do you mean by "needs some thought" (in the ticket notes)? > > I hadn't decided yet if slapd should log a warning for this or not. A warning, to be useful, should allow to clearly identify the broken piece of data. Where the issue is identified, there's no way to find out the DN of the entry that contains the datum. All you could use is the certificate's content (e.g. issuer DN and so); not sure how helpful it would be. p.

1 0

Re: (ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by hyc＠symas.com 01 Feb '10

01 Feb '10

Erwann Abalea wrote: > Hodie III Kal. Feb. MMX, Howard Chu scripsit: (Sorry, just had to laugh, using a ~3000 year old language in email...) >> erwann.abalea(a)keynectis.com wrote: >> Also note that, technically, LDAP is defined to conform to the 1993 >> edition of the X.500 specs, and X.509(1993) makes no such allowance >> here. > > I didn't know that LDAP was designed to conform to a specific edition > of the standard. Isn't that strange? After all, it should also refuse > to handle X.509v2 CRLs, and X.509v3 certificates, which appear for the > first time in the 1997 edition. > Anyway, I hadn't thought about looking at older revisions of the X.509 > standard. You're right, my 1997 edition doesn't say anything about > this, and my 2000 edition (a french version) has the same text as the > 2005 one. See RFC4510, section 2. Yes, it's certainly an inconsistency in the LDAP spec, that RFC4513 requires use of subjectAltNames which clearly require X.509v3 certs but the only normative references to the necessary edition of X.509 is outside the core specification. (Looking again I see that RFC4523 references X.509(2000) so it appears that some portions of newer X.500 editions are being incorporated, piecemeal...) > Anyway, thank you again. I'll test the head version and will come back > later. > BTW, what do you mean by "needs some thought" (in the ticket notes)? I hadn't decided yet if slapd should log a warning for this or not. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by erwann.abalea＠keynectis.com 01 Feb '10

01 Feb '10

Hodie III Kal. Feb. MMX, Howard Chu scripsit: > erwann.abalea(a)keynectis.com wrote: > >When no certificate is revoked, the revokedCertificate element SHOULD be > >omitted, instead of being included as an empty SEQUENCE OF SEQUENCE. RFC5280 has > >changed the SHOULD into a MUST, but I don't think this is checked by the > >function. I think it only skips over the next element (in my case, the > >crlExtensions). > > Thanks for the report. The code in CVS HEAD has been patched to > silently accept this case. However, it's worth pointing out that > even in X.509(2005): Thank you for having corrected it. > >>>> > If none of the certificates covered by this CRL have been revoked, > it is strongly recommended that > revokedCertificates parameter be omitted from the CRL, rather than being > included with an empty SEQUENCE. > <<<< That's what I meant to write when I wrote that the element SHOULD be omitted. X.509 doesn't prevent such an empty sequence, it only strongly recommends to avoid it. A strong recommendation in ISO terminology is as a SHOULD in RFC2119 meaning. You're right, here. > Also note that, technically, LDAP is defined to conform to the 1993 > edition of the X.500 specs, and X.509(1993) makes no such allowance > here. I didn't know that LDAP was designed to conform to a specific edition of the standard. Isn't that strange? After all, it should also refuse to handle X.509v2 CRLs, and X.509v3 certificates, which appear for the first time in the 1997 edition. Anyway, I hadn't thought about looking at older revisions of the X.509 standard. You're right, my 1997 edition doesn't say anything about this, and my 2000 edition (a french version) has the same text as the 2005 one. > We may consider logging a warning for this case. What software > generated this CRL? It seems to be defective... At first, I also thought it was defective. But after all, the standard doesn't say that this revokedCertificates element MUST be eliminated when no certificate is revoked (I use RFC2119 terminology here, but you certainly got it). I certainly will produce a warning to the software vendor, though. In general, I tend to follow "SHOULD" rules. I don't know what software produced this CRL (yet), I only know who uses it (one of our customers). I'll get in touch with them for that. In the same time, I'll check that we correctly do our job (we're also a PKI software vendor). Anyway, thank you again. I'll test the head version and will come back later. BTW, what do you mean by "needs some thought" (in the ticket notes)? -- Erwann ABALEA <erwann.abalea(a)keynectis.com> ----- "Common sense is the collection of prejudices acquired by age 18." - Albert Einstein

1 0

Re: (ITS#6464) Buffer overflow
by hyc＠symas.com 31 Jan '10

31 Jan '10

csdr(a)lthd.com wrote: > Full_Name: Chis-Serban Dinu-Razvan > Version: 2.4.21 > OS: Fedora 12 > URL: http://lthd.com/out1.txt > Submission from: (NULL) (193.231.233.40) > > > I have a master ldap server running openldap 2.4.21 and 3 replicas running > 2.4.15 and 2.4.19 and I when I try to delete/rename an object, the master dies > with an buffer overflow error. I mention that before the master was 2.4.15 and > the replica running 2.4.19 died. I have updated the master to 2.4.19 and it > start dyeing. Then I upgraded it to 2.4.21 an it still dies. It dies even if the > syncprov is off. > Please provide a stack trace from this crash. Be sure to compile with debug symbols enabled and no optimization, otherwise we won't be able to track anything down. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by hyc＠symas.com 30 Jan '10

30 Jan '10

erwann.abalea(a)keynectis.com wrote: > Full_Name: Erwann Abalea > Version: 2.4.17 > OS: Debian/testing > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.167.155.1) > > > As indicated in the subject, certificateListValidate() doesn't validate some > valid CRLs. Those CRLs are valid from X.509 point of view, but do not conform to > RFC5280 (which is only a profile of the standard). > > When no certificate is revoked, the revokedCertificate element SHOULD be > omitted, instead of being included as an empty SEQUENCE OF SEQUENCE. RFC5280 has > changed the SHOULD into a MUST, but I don't think this is checked by the > function. I think it only skips over the next element (in my case, the > crlExtensions). Thanks for the report. The code in CVS HEAD has been patched to silently accept this case. However, it's worth pointing out that even in X.509(2005): >>>> If none of the certificates covered by this CRL have been revoked, it is strongly recommended that revokedCertificates parameter be omitted from the CRL, rather than being included with an empty SEQUENCE. <<<< Also note that, technically, LDAP is defined to conform to the 1993 edition of the X.500 specs, and X.509(1993) makes no such allowance here. We may consider logging a warning for this case. What software generated this CRL? It seems to be defective... > Here's a real-life CRL: > certificateRevocationList;binary:: MIIBPTCBpwIBATANBgkqhkiG9w0BAQUFADAkMQswCQY > DVQQGEwJGUjEVMBMGA1UEChMMR0lQLUNQUy1URVNUFw0wOTA5MTcxMDEyNTdaFw0xMDA2MjQxMDEy > NTdaMACgTTBLMB8GA1UdIwQYMBaAFOH6F/gUI8Xen3tJVqLlQphs5EovMAoGA1UdFAQDAgECMBwGA > 1UdEgQVMBOBEWFjLWdpcEBnaXAtY3BzLmZyMA0GCSqGSIb3DQEBBQUAA4GBAByCwHi4fZG95ScpLO > 2HW+5I1zeodXlbTOCgnbLVLLz0WjXXZpa5ecn2aHpqrc5L70UIKBhrk/LJ8+y03UBtx6z1gdGNL3u > +rbVQcMgbKJ5AbLojfyWeS4d6n8TZBlM0Wd5eJ6AlwPKRvNV//QH3vjMPVWeD2XYtwQhBYqEGJrvn > > And a real-life deltaCRL: > deltaRevocationList;binary:: MIIBTjCBuAIBATANBgkqhkiG9w0BAQUFADAkMQswCQYDVQQGE > wJGUjEVMBMGA1UEChMMR0lQLUNQUy1URVNUFw0wODEyMjQwMzAwMjNaFw0wODEyMzAwMzAwMjNaMA > CgXjBcMB8GA1UdIwQYMBaAFOH6F/gUI8Xen3tJVqLlQphs5EovMAsGA1UdFAQEAgIKAjAOBgNVHRs > BAf8EBAICCgEwHAYDVR0SBBUwE4ERYWMtZ2lwQGdpcC1jcHMuZnIwDQYJKoZIhvcNAQEFBQADgYEA > gEk/dBR5Vz+RtfBp4hpPaSX1aXFAzx6pZCSBaQ4dFfbXV9HkbPM/2dh32HRDueyhJnXmfn/m5Q9Vo > syEzF1MQEDYZV0A5Liu8oiZtY9gfe522pz7+oehZdOyzkLx6nUw6uLLTL62q8lRbDsNbZNsu22sz7 > dAucnBo63ksdGgdFQ= > > You'll see empty SEQUENCEs. Bug probably around line 314 of file schema_init.c, > but I don't know openldap internals enough to correct it by myself. > > Thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by erwann.abalea＠keynectis.com 29 Jan '10

29 Jan '10

Full_Name: Erwann Abalea Version: 2.4.17 OS: Debian/testing URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.167.155.1) As indicated in the subject, certificateListValidate() doesn't validate some valid CRLs. Those CRLs are valid from X.509 point of view, but do not conform to RFC5280 (which is only a profile of the standard). When no certificate is revoked, the revokedCertificate element SHOULD be omitted, instead of being included as an empty SEQUENCE OF SEQUENCE. RFC5280 has changed the SHOULD into a MUST, but I don't think this is checked by the function. I think it only skips over the next element (in my case, the crlExtensions). Here's a real-life CRL: certificateRevocationList;binary:: MIIBPTCBpwIBATANBgkqhkiG9w0BAQUFADAkMQswCQY DVQQGEwJGUjEVMBMGA1UEChMMR0lQLUNQUy1URVNUFw0wOTA5MTcxMDEyNTdaFw0xMDA2MjQxMDEy NTdaMACgTTBLMB8GA1UdIwQYMBaAFOH6F/gUI8Xen3tJVqLlQphs5EovMAoGA1UdFAQDAgECMBwGA 1UdEgQVMBOBEWFjLWdpcEBnaXAtY3BzLmZyMA0GCSqGSIb3DQEBBQUAA4GBAByCwHi4fZG95ScpLO 2HW+5I1zeodXlbTOCgnbLVLLz0WjXXZpa5ecn2aHpqrc5L70UIKBhrk/LJ8+y03UBtx6z1gdGNL3u +rbVQcMgbKJ5AbLojfyWeS4d6n8TZBlM0Wd5eJ6AlwPKRvNV//QH3vjMPVWeD2XYtwQhBYqEGJrvn And a real-life deltaCRL: deltaRevocationList;binary:: MIIBTjCBuAIBATANBgkqhkiG9w0BAQUFADAkMQswCQYDVQQGE wJGUjEVMBMGA1UEChMMR0lQLUNQUy1URVNUFw0wODEyMjQwMzAwMjNaFw0wODEyMzAwMzAwMjNaMA CgXjBcMB8GA1UdIwQYMBaAFOH6F/gUI8Xen3tJVqLlQphs5EovMAsGA1UdFAQEAgIKAjAOBgNVHRs BAf8EBAICCgEwHAYDVR0SBBUwE4ERYWMtZ2lwQGdpcC1jcHMuZnIwDQYJKoZIhvcNAQEFBQADgYEA gEk/dBR5Vz+RtfBp4hpPaSX1aXFAzx6pZCSBaQ4dFfbXV9HkbPM/2dh32HRDueyhJnXmfn/m5Q9Vo syEzF1MQEDYZV0A5Liu8oiZtY9gfe522pz7+oehZdOyzkLx6nUw6uLLTL62q8lRbDsNbZNsu22sz7 dAucnBo63ksdGgdFQ= You'll see empty SEQUENCEs. Bug probably around line 314 of file schema_init.c, but I don't know openldap internals enough to correct it by myself. Thanks.

1 0

(ITS#6465) startup error after converting to slapd-config
by gerard.ranke＠kmt.hku.nl 29 Jan '10

29 Jan '10

Full_Name: Gerard Ranke Version: 2.4.21 OS: IRIX 6.5.30 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.87.216.230) We run openLDAP 2.4.21 on one master plus 7 slaves. Some time ago ( I believe we were on 2.4.19 at the time ), I converted one of the slaves to slapd-config from slapd.conf to get myself acquainted with it, and that went without problems. Now, if I try the conversion with slaptest -f slapd.conf -F slapd.d, the conversion works ok, but slapd won't start, and gives this error: Jan 18 15:30:20 7E:example-slave slapd[1741992]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb Jan 18 15:30:20 7U:example-slave slapd[1741992]: olcSyncrepl: value #0: <olcSyncrepl> invalid URL Jan 18 15:30:20 7U:example-slave slapd[1741992]: config error processing olcDatabase={1}hdb,cn=config: <olcSyncrepl> invalid URL Jan 18 15:30:20 7U:example-slave slapd[1741992]: slapd stopped. Jan 18 15:30:20 7U:example-slave slapd[1741992]: connections_destroy: nothing to destroy. I noticed that the olcSyncrepl in olcDatabase={1}hdb,cn=config changed from: olcSyncrepl: rid=001 provider=ldap://masterldap.example.com:389 bindmethod=simple timeout =0 network-timeout=0 binddn="cn=syncuser,dc=example,dc=com" credentials="xxxxxxxxx " starttls=critical filter="(objectClass=*)" searchbase="dc=example,dc=com" scope= sub attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 5 10 +" for the older openldap version, to: olcSyncrepl: rid=001 provider=ldap://masterldap.example.com:389 uri="" bindmethod=simple timeout=0 network-timeout=0 binddn="cn=syncuser,dc=example,dc=com" credentials="xxxxxxxxx" starttls=critical tls_cert="/usr/ssl/certs/examplewildcard.cert " tls_key="/usr/ssl/certs/examplewildcard.key" tls_cacert="/usr /ssl/certs/cacert_root.crt" tls_reqcert=demand tls_crlcheck=none filter="(obj ectClass=*)" searchbase="dc=example,dc=com" scope=sub attrs="*,+" schemachecking=o ff type=refreshAndPersist retry="5 5 10 +" for 2.4.21. Notice the ' uri="" ' in the last version. Fortunately, if I remove the empty uri assignment from the ldif file, slapd starts normally. I also noticed the slaves which I converted earlier ( so which had the first olcSyncrepl 'format' above ) didn't replicate properly ( contextcsn also lagging behind ). I shut down slapd on these machines, cleaned out slapd.d, converted again, removed the 'uri=""' and restarted. After that, the replication caught up by itself. Thanks for your attention for this!

1 0

(ITS#6464) Buffer overflow
by csdr＠lthd.com 28 Jan '10

28 Jan '10

Full_Name: Chis-Serban Dinu-Razvan Version: 2.4.21 OS: Fedora 12 URL: http://lthd.com/out1.txt Submission from: (NULL) (193.231.233.40) I have a master ldap server running openldap 2.4.21 and 3 replicas running 2.4.15 and 2.4.19 and I when I try to delete/rename an object, the master dies with an buffer overflow error. I mention that before the master was 2.4.15 and the replica running 2.4.19 died. I have updated the master to 2.4.19 and it start dyeing. Then I upgraded it to 2.4.21 an it still dies. It dies even if the syncprov is off.

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 27 Jan '10

27 Jan '10

--0-1999948331-1264610847=:54320 Content-Type: text/plain; charset=us-ascii We found out that this call : ldap_msgfree(res); does not get executed because the LDAPMessage is NULL (res is null) in case the timeout is on the client side. There is any other way to clean it? --0-1999948331-1264610847=:54320 Content-Type: text/html; charset=us-ascii <table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">We found out that this call :<br><br>ldap_msgfree(res);<br><br>does not get executed because the LDAPMessage is NULL (res is null) in case the timeout is on the client side.<br><br>There is any other way to clean it?<br></td></tr></table><br> --0-1999948331-1264610847=:54320--

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 27 Jan '10

27 Jan '10

--0-1407467353-1264601923=:2093 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =A0 A similar issue was found in Netscape SDK :=A0 http://www.mail-archive.= com/mozilla-directory(a)mozilla.org/msg01734.html =0A=0A=0A --0-1407467353-1264601923=:2093 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"= top" style=3D"font: inherit;">  A similar issue was found in Netscape = SDK :  http://www.mail-archive.com/mozilla-directory@mozilla.org/msg01= 734.html<br><br></td></tr></table><br>=0A=0A --0-1407467353-1264601923=:2093--

1 0

memberof overlay
by Daniel Gomes 27 Jan '10

27 Jan '10

Dear list members, I have been trying to get the memberof overlay to work properly on slapd 2.4.19 on an Ubuntu hardy (8.04.3). After realizing (which took a while hehe) that installing OpenLDAP via apt-get wouldn't allow me to enable modules/overlays, I downloaded the source and built it manually with: ./configure --enable-overlays --enable-accesslog --enable-auditlog --enable-collect --enable-constraint --enable-dds --enable-deref --enable-dyngroup --enable-dynlist --enable-memberof --enable-ppolicy --enable-proxycache --enable-refint --enable-retcode --enable-rwm --enable-seqmod --enable-syncprov --enable-translucent --enable-unique --enable-valsort --enable-modules --with-tls (I wanted to be on the safe side so I kinda enabled everything) The server is now set up and running (with TLS and all, but I guess that's not important here). To activate the wanted overlay, I have (on my slapd.conf): modulepath /usr/local/etc/openldap/overlays/ moduleload memberof.la overlay memberof (the path is correct and I have checked the logs to make sure he was paying attention to those fields). Anyway, I starting making some experiences, and at first it seemed to be working fine. But some test cases later, the memberOf value started being incorrect, when comparing to the member attribute of the groups. Here's how to reproduce my scenario (I just tried it again, with a new database, base DN being dc=ipfn,dc=ist,dc=utl,dc=pt): First, run init.ldif (attached), which creates the usual groups and people OU's, creates 2 users followed by 2 group with one user per group. So far so good, if I make a ldapsearch based on ou=people (...) and ask for the memberOf attribute, I get: dn: ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=Daniel Gomes,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt memberOf: cn=admin,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=John Smith,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt memberOf: cn=users,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt ---------------------------------------- Next, I run modify.ldif (also attached) which changes the member attribute of the admin group from "cn=Daniel Gomes (...)" to "cn=John Smith (...)". We can then see that: dn: ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt objectClass: organizationalUnit ou: groups dn: cn=admin,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt objectClass: groupOfNames cn: admin description: For administrators member: cn=John Smith,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=users,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt objectClass: groupOfNames cn: users description: For users member: cn=John Smith,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt ---------------------------------------------- Meaning, the group was successfully modified, but the previous query returns the same value: dn: ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=Daniel Gomes,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt memberOf: cn=admin,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=John Smith,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt memberOf: cn=users,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt ----------------------------------------- This seems to happen only when deleting users from groups. I have tried with and without the refint overlay, if that matters for anything. Anyway, I do not see anything I can be doing wrong, so it does seem to be a bug. If I could get some info on this, I would appreciate it! Cheers, -- Daniel Gomes (SysAdmin) dgomes(a)ipfn.ist.utl.pt Ext. 3487 - 218419487 Instituto de Plasmas e usão Nuclear Instituto Superior Técnico - UTL Av. Rovisco Pais - 1049-001 Lisboa - Portugal

1 0

Re: (ITS#6462) DNS SRV records: ldaps ???
by quanah＠zimbra.com 27 Jan '10

27 Jan '10

--On Wednesday, January 27, 2010 1:28 AM +0000 jochen(a)keutel.de wrote: > Full_Name: Jochen Keutel > Version: 2.4.21 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > protocol is either "ldap" oder "ldaps". LDAPS is not a defined protocol. I would suggest using LDAP with startTLS, which is RFC Defined. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6463) dnssrv_back_referrals: ldaps not handled, search base gone
by jochen＠keutel.de 27 Jan '10

27 Jan '10

Full_Name: Jochen Keutel Version: 2.4.21 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.159.206.14) dnssrv_back_referrals() always returns ldap URLs - even when the original request was a ldaps query. Additionally only protocol and hostname are put into the URL - the search base doesn't appear any more. Problematic code: url.bv_len = STRLENOF( "ldap://" ) + strlen( hosts[i] ); url.bv_val = ch_malloc( url.bv_len + 1 ); strcpy( url.bv_val, "ldap://" ); strcpy( &url.bv_val[STRLENOF( "ldap://" )], hosts[i] ); I'm not sure whether you want me to deliver a complete patch or not ... Thanks to my colleague Manuel Gaupp for detecting this problem. Best regards, Jochen.

1 0

(ITS#6462) DNS SRV records: ldaps ???
by jochen＠keutel.de 27 Jan '10

27 Jan '10

Full_Name: Jochen Keutel Version: 2.4.21 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.159.206.14) The code for detecting LDAP servers via DNS SRV records seems to handle only ldap URLs - not ldaps URLs. Esp.: If you access an OpenLDAP server with ldaps://host1/..., then the DNS SRV code returns a URL like ldap://host2/... . So the LDAP server chains the original ldaps request as a LDAP query without TLS. This gets problematic when the (company / project) requirements clearly state that only ldaps has to be used ... The problematic code seems to be in libraries/libldap/dnssrv.c, function ldap_domain2hostlist(): request = LDAP_MALLOC(strlen(domain) + sizeof("_ldap._tcp.")); ... sprintf(request, "_ldap._tcp.%s", domain); So always "_ldap._tcp" is used (hard coded) - not "ldaps._tcp" in case of ldaps in the original query. I'd suggest to introduce a third parameter to that function: int ldap_domain2hostlist( LDAP_CONST char *protocol, LDAP_CONST char *domain, char **list ) protocol is either "ldap" oder "ldaps". The code calling this function (slapd/back-dnssrv/search.c and referral.c) has to be adjusted as well. I'm not sure whether you want me to deliver a complete patch or not ... Thanks to my colleague Manuel Gaupp for detecting this problem. Best regards, Jochen.

1 0

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

25 Jan '10

Guillaume.Rousse(a)inria.fr wrote: > Le 18/01/2010 17:13, masarati(a)aero.polimi.it a écrit : >> Could not reproduce. Apparently, it's something else that's creating >> hassle. Please provide a stack backtrace. > > Actually, it's an assertion failure un entry.c: > slapd: entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' > failed. > Abandon > > Here the backtrace, but compilation optimisation may hinder its usability: Well, at least it shows where the failure is. However, since I can't reproduce it, I'll need your (sanitized) slapd.conf, a LDIF to load and the operation that causes the failure. p.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by masarati＠aero.polimi.it 25 Jan '10

25 Jan '10

Howard Chu wrote: > masarati(a)aero.polimi.it wrote: >>> * masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: >>>> Funny enough, the same thing is dealt with correctly in certificate >>>> validation/normalization in slapd/schema_init.c >>> That was a result of ITS#5070 (which you filed). >> right :) >> >>> Maybe there is an >>> opportunity for refactoring, but I wouldn't be a good judge of that. >> I don't quite bother about refactoring to minimize code duplication. >> Rather, I think the libldap function x509_cert_get_dn() should first >> validate the certificate, much like slapd's certificateValidate() does. > > Since the cert was obtained thru a TLS handshake, we assume it has already > been validated by the TLS library. Further validation is not needed. What I mean is that the TLS library may handle certificates that our function does not like (as in this case). Slapd's code, while skipping fields, checks their tags. We should do the same here, IMHO. p.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by hyc＠symas.com 24 Jan '10

24 Jan '10

masarati(a)aero.polimi.it wrote: >> * masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: >>> Funny enough, the same thing is dealt with correctly in certificate >>> validation/normalization in slapd/schema_init.c >> >> That was a result of ITS#5070 (which you filed). > > right :) > >> Maybe there is an >> opportunity for refactoring, but I wouldn't be a good judge of that. > > I don't quite bother about refactoring to minimize code duplication. > Rather, I think the libldap function x509_cert_get_dn() should first > validate the certificate, much like slapd's certificateValidate() does. Since the cert was obtained thru a TLS handshake, we assume it has already been validated by the TLS library. Further validation is not needed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6461) back-sql quote characters in query
by tolich.arz＠gmail.com 24 Jan '10

24 Jan '10

Full_Name: Anatoly Version: 2.4.19 OS: GNU/Linux URL: Submission from: (NULL) (89.169.85.181) I'm using openldap 2.4.19 with sql backend. I have a troubles with queries that contains single-quote ( ' ) character. For example, if I searching for (cn=Zool'man): <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,phpbb_users.user_id,varchar_ci('phpbbUser') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,phpbb_users WHERE phpbb_users.user_id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND (varchar_ci(phpbb_users.username)='ZOOL'MAN') Constructed query: SELECT DISTINCT ldap_entries.id,phpbb_users.user_id,varchar_ci('phpbbUser') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,phpbb_users WHERE phpbb_users.user_id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND (varchar_ci(phpbb_users.username)='ZOOL'MAN') id: '2' backsql_oc_get_candidates(): error executing query Return code: -1 nativeErrCode=7 SQLengineState=S1000 msg="[unixODBC]ERROR: syntax error at or near "MAN" at character 271; In this case query should be like varchar_ci(phpbb_users.username)='ZOOL\'MAN' instead of 'ZOOL'MAN' Additionally, I fear this opens a possibility of sql injection, depending on RDBMS.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by Sergio.Gelato＠astro.su.se 24 Jan '10

24 Jan '10

* masarati(a)aero.polimi.it [2010-01-24 19:14:02 +0100]: > I'm applying the fix, please test. I'm in production with the fix (on 2.4.11; I don't have the time to deploy HEAD right now). syncrepl (which is what I'm using SASL EXTERNAL for) now works again. As for the need to validate the certificate: shouldn't this have been taken care of during the preceding TLS handshake?

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by masarati＠aero.polimi.it 24 Jan '10

24 Jan '10

> * masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: >> Funny enough, the same thing is dealt with correctly in certificate >> validation/normalization in slapd/schema_init.c > > That was a result of ITS#5070 (which you filed). right :) > Maybe there is an > opportunity for refactoring, but I wouldn't be a good judge of that. I don't quite bother about refactoring to minimize code duplication. Rather, I think the libldap function x509_cert_get_dn() should first validate the certificate, much like slapd's certificateValidate() does. I'm applying the fix, please test. p.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by Sergio.Gelato＠astro.su.se 24 Jan '10

24 Jan '10

* masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: > Funny enough, the same thing is dealt with correctly in certificate > validation/normalization in slapd/schema_init.c That was a result of ITS#5070 (which you filed). Maybe there is an opportunity for refactoring, but I wouldn't be a good judge of that.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by masarati＠aero.polimi.it 24 Jan '10

24 Jan '10

> Full_Name: Sergio Gelato > Version: 2.4.11 (problem also in HEAD) > OS: Debian GNU/Linux > URL: > Submission from: (NULL) (85.225.123.197) > > > Using (X.509 certificate-based) SASL EXTERNAL authentication fails when > the > serial number of the certificate is longer than 4 octets. > > I have traced the problem to the use, by > libraries/libldap/tls.c:x509_cert_get_dn(), > of ber_get_int() to consume the serial number. This fails when the value > to be > decoded > doesn't fit in a ber_int_t. > > I discovered this bug with Debian's OpenLDAP 2.4.11-1+lenny1 but a look at > the > OpenLDAP CVS indicates that the problem is still present in the current > HEAD > (1.167). > > I've successfully tested the following patch: > ==================================================================================== > RFC5280 §4.1.2.2 says "[c]ertificate users MUST be able to handle > serialNumber > values up to 20 octets". ber_get_int() fails beyond 4 octets. Since we > don't > actually care about the certificate serial number, let's just skip it. > > --- a/libraries/libldap/tls.c > +++ b/libraries/libldap/tls.c > @@ -1673,7 +1673,8 @@ > tag = ber_skip_tag( ber, &len ); /* Context + Constructed (version) */ > if ( tag == 0xa0 ) /* Version is optional */ > tag = ber_get_int( ber, &i ); /* Int: Version */ > - tag = ber_get_int( ber, &i ); /* Int: Serial */ > + tag = ber_skip_tag( ber, &len ); /* *Big* integer: Serial */ > + ber_skip_data( ber, len ); > tag = ber_skip_tag( ber, &len ); /* Sequence: Signature */ > ber_skip_data( ber, len ); > if ( !get_subject ) { Funny enough, the same thing is dealt with correctly in certificate validation/normalization in slapd/schema_init.c p.

1 0

(ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by Sergio.Gelato＠astro.su.se 23 Jan '10

23 Jan '10

Full_Name: Sergio Gelato Version: 2.4.11 (problem also in HEAD) OS: Debian GNU/Linux URL: Submission from: (NULL) (85.225.123.197) Using (X.509 certificate-based) SASL EXTERNAL authentication fails when the serial number of the certificate is longer than 4 octets. I have traced the problem to the use, by libraries/libldap/tls.c:x509_cert_get_dn(), of ber_get_int() to consume the serial number. This fails when the value to be decoded doesn't fit in a ber_int_t. I discovered this bug with Debian's OpenLDAP 2.4.11-1+lenny1 but a look at the OpenLDAP CVS indicates that the problem is still present in the current HEAD (1.167). I've successfully tested the following patch: ==================================================================================== RFC5280 §4.1.2.2 says "[c]ertificate users MUST be able to handle serialNumber values up to 20 octets". ber_get_int() fails beyond 4 octets. Since we don't actually care about the certificate serial number, let's just skip it. --- a/libraries/libldap/tls.c +++ b/libraries/libldap/tls.c @@ -1673,7 +1673,8 @@ tag = ber_skip_tag( ber, &len ); /* Context + Constructed (version) */ if ( tag == 0xa0 ) /* Version is optional */ tag = ber_get_int( ber, &i ); /* Int: Version */ - tag = ber_get_int( ber, &i ); /* Int: Serial */ + tag = ber_skip_tag( ber, &len ); /* *Big* integer: Serial */ + ber_skip_data( ber, len ); tag = ber_skip_tag( ber, &len ); /* Sequence: Signature */ ber_skip_data( ber, len ); if ( !get_subject ) {

1 0

Re: (ITS#6364) refint needs to have rootdn set
by apm＠mutex.dk 22 Jan '10

22 Jan '10

This may be related. I've veryfied that my refint overlay is not working. However I have a rootdn defined for the database, but it is set to cn=config. Could it be that the rootdn has to be in the scope of the database for refint to work? slapd 2.4.20, back-hdb, BerkeleyDB 4.8.24 /Peter

1 0

(ITS#6459) memory leak in syncprov
by rhafer＠suse.de 21 Jan '10

21 Jan '10

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.21.216) When sending SYNC_NEW_COOKIE intermedia results syncprov_qplay() does not free the entry from the syncres structure. A fix is on the way...

1 0

(ITS#6458) syncrepl fails if attribute has no equalty maching rule
by pcernko+openldap＠mpi-sws.org 20 Jan '10

20 Jan '10

Full_Name: Patrick Cernko Version: 2.4.21 OS: Linux URL: http://www.mpi-inf.mpg.de/~pcernko/syncrepl_fails_if_attribute_has_no_equal… Submission from: (NULL) (139.19.3.67) Hi OpenLDAP-Programmers, although some related bug reports were posted in the past years, this issue still seems not to be fixed: OpenLDAP's syncrepl replication fails if it comes to removing one of a multi-value attribes of an object if this attribute does not have a equality matching rule defined in the schema. Modification works on the master server but fails to replicate to the slave(s) leaving them with the dit version just before and not replicating any other changes any more. I compiled a small example how to reproduce the problem with the (maybe "well-known") nisNetgroupTriple attribute from nis.schema as shipped with openldap-2.4.21: - extract the files from http://www.mpi-inf.mpg.de/~pcernko/syncrepl_fails_if_attribute_has_no_equal… into an empty working directory - download the tarball to that working dir and configure similar to the just extracted configure.sh - build and install it to get an install subdir in the working dir - start the master using sh master.sh in the working dir This will create the "master" database in your working dir, slapadd the dit.ldif and start a master slapd with a unix socket /tmp/master. - start the slave using sh slave.sh This will create "slave" database in your working dir and start the slave slapd with a unix socket /tmp/slave which will immediately start syncing from the running master - if you want you can search the 2 servers with install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL resp. install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL - use "python mod.py" to remove one of the nisNetgroupTriple attributes from the netgroup object - you will see a debug message from the slave server like this: bdb_modify_internal: delete nisNetgroupTriple bdb_modify_internal: 18 modify/delete: nisNetgroupTriple: no equality matching rule send_ldap_result: err=18 matched="" text="modify/delete: nisNetgroupTriple: no equality matching rule" null_callback : error code 0x12 slap_graduate_commit_csn: removing 0x29931c0 20100120124712.028626Z#000000#000#000000 syncrepl_entry: rid=001 be_modify cn=netgroup,ou=openldap (18) syncrepl_entry: rid=001 be_modify failed (18) if not, use "python mod.py add" to re-add the removed nisNetgroupTriple and try again. Sometimes, it seems to work (race condition?). - you can also verify the difference with: install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL cn=netgroup install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL cn=netgroup - from now on, the slave will fail to sync any succeeding changes, as it continuously tries to sync the modification above first. :-( Now, obviously having an attribute without equality matching rule is not a good idea in the first place. However, the (official?) nis.schema comes with such an attribute which we must use like this (e.g. we would have to patch the Solaris kernel to change it for the Solaris NFS server). It is possible to modify a nisNetgroup object like this: according to the debugging output, I guess the master removes simply ALL nisNetgroupTriple attributes and adds only the attributes that should remain. When the corresponding syncrepl_entry is handled by the slave, it seems the it in contrast tries to really only remove the 2-be-removed attribute which does not work as it cannot identify the right one due to a missing eq-match operator. I suggest the best way to solve this issue is to try to get syncrepl do exactly the same actions (not resulting changes) as the server does.

1 0

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

20 Jan '10

Le 18/01/2010 17:13, masarati(a)aero.polimi.it a écrit : > Could not reproduce. Apparently, it's something else that's creating > hassle. Please provide a stack backtrace. Actually, it's an assertion failure un entry.c: slapd: entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' failed. Abandon Here the backtrace, but compilation optimisation may hinder its usability: #0 0x00007ffff6476955 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 pid = <value optimized out> selftid = <value optimized out> #1 0x00007ffff6477f70 in abort () at abort.c:92 act = {__sigaction_handler = {sa_handler = 0x5068de, sa_sigaction = 0x5068de}, sa_mask = {__val = {140737326326544, 140737233550016, 483, 140737233550256, 140737325461350, 206158430232, 140737233550272, 140737233550048, 140737325372360, 206158430256, 140737233550296, 140737019750384, 117, 117, 0, 140737488347048}}, sa_flags = -162034579, sa_restorer = 0x50a16f} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007ffff646f861 in __assert_fail (assertion=0x5068de "e->e_private == ((void *)0)", file=<value optimized out>, line=483, function=0x506d68 "entry_clean") at assert.c:81 buf = 0x7fffe411a7f0 "slapd: entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' failed.\n" #3 0x000000000043c9f8 in entry_clean (e=0xbcf148) at entry.c:483 __PRETTY_FUNCTION__ = "entry_clean" #4 0x000000000043ca1d in entry_free (e=0x2997) at entry.c:514 No locals. #5 0x00000000004430f7 in slap_send_search_entry (op=0x7fffe4002950, rs=0x7ffff0e81a20) at result.c:1310 berbuf = { buffer = "\000\000\001\000\000\000\000\000?\020", '\000' <repeats 14 times>, "]\240\326\331d\355\343P\000\000\000\000\000\000\000\000]\240\326\331d\355\343Pp\265\211\000\000\000\000\000\354\237C\000\000\000\000\000\200@\000\344\377\177\000\000]\240\326\331d\355\343P\370\360\274\000\000\000\000\000\020\343\177\000\000\000\000\000\200@\000\344\377\177\000\000\v\031E", '\000' <repeats 13 times>, "\004\000\000\000\000\000\000\000\260\375\317\360\377\177", '\000' <repeats 18 times>, "\004", '\000' <repeats 102 times>, ialign = 65536, lalign = 65536, falign = 9.18354962e-41, dalign = 3.2379086165851934e-319, palign = 0x10000 <Address 0x10000 out of bounds>} ber = 0x7fffe4002950 a = 0x80bf90 i = 1 j = <value optimized out> rc = 0 bytes = 8437648 userattrs = 0 acl_state = {as_desc = 0x0, as_access = ACL_NONE, as_vd_acl = 0x0, as_vd_acl_count = 0, as_vd_mask = 1, as_result = -1, as_fe_done = 0} attrsonly = 0 ad_entry = 0x80bf90 e_flags = 0x0 #6 0x00000000004b407c in bdb_search (op=0x7fffe4002950, rs=0x7ffff0e81a20) at search.c:961 bois = {boi_oe = {oe_next = {sle_next = 0x7ffff0e80480}, oe_key = 0x89b570}, boi_txn = 0x0, boi_locks = 0x7ffff0cfff70, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 1 '\001'} blis = {bli_next = 0x0, bli_lock = {off = 398968, ndx = 98, gen = 2, mode = DB_LOCK_READ}, bli_id = 4, bli_flag = 1} scopeok = 1 bdb = 0x89b570 id = 4 cursor = 4 lastid = 18446744073709551615 candidates = {18446744073709551615, 2, 4, 4, 0, 7, 140737019654336, 0, 0, 0, 0, 140737018603728, 0, 398968, 4294967394, 1, 4, 1, 0, 9024880, 0, 140737233551920, 1099511627776, 0 <repeats 31 times>, 140737018605160, 0, 161, 140737018605160, 0, 0, 0, 0, 0, 0, 160, 140737233552240, 0, 0, 0, 4294967394, 1, 0, 0, 0, 7, 140737019654336, 0, 0, 0, 0, 0, 140737019653408, 4159, 140737019655616, 0, 18446744073709551615, 5, 8589934592, 18446744073709551615, 1, 4, 0 <repeats 130981 times>} scopes = {0 <repeats 63786 times>, 64, 0, 0, 0, 0, 0, 64, 0, 0, 206158430210, 532575944795, 140737018593312, 2064, 140737018593312, 2896, 140737019704496, 140737018593416, 140737325535154, 90, 2048, 140737019704256, 80, 6, 32, 4, 0, 2096, 0, 0, 343597383809, 532575944799, 472446402679, 0, 24, 2048, 140737018593312, 2896, 140737019704496, 140737328631424, 140737325539706, 0, 3, 140737235123824, 140737235111168, 140737235111216, 140737235111120, 3, 140737325789440, 140737019662880, 140737019703776, 140737019660544, 140737019662880, 140737019704032, 140737019660544, 140737019662880, 140737019704256, 140737019660544, 140737235123824, 140737235111168, 140737325790836, 8589934594, 140737018603072, 8589934594, 140737019662800, 4294967297, 140737019690064, 8589934594, 140737019662832, 4294967297, 140737019690064, 0 <repeats 502 times>, 17592186044416, 0, 0, 0, 0, 1048576, 0, 0, 18446726481523507198, 18446744073708503039, 18446744073709551615, 18446744073709551615, 0, 16, 0, 0, 18446726477228539902, 18446744073709518831, 18446744073709551615, 18446744073709551615, 0 <repeats 425 times>, 140737325961225, 0, 140737326101420, 90194321408, 0, 3590586904199757824, 140737235118896, 0, 0, 12884908544, 0, 4898288851081953280, 140737235118944, 0, 0, 4294969344, 0, 72058143793676288, 0, 0, 140737326101420, 562962838323220, 45729780788658, 4294967296, 72058139498840072, 72058139498905608, 122509647347719, 563035852767292, 45729780788658, 12893297154, 4898288846787117064, 4898288846787182600, 9221744489062989832, 3488165888539164681, 257698037760, 5428787749601804308, 36063989980998039, 281509336449045, 562985149158339, 1125935102579651, 844464420836291, 812545396, 0 <repeats 48 times>, 140737325961225, 0, 140737326101420, 90194321408, 0, 3590586904199757824, 140737235119616, 0, 0, 12884908544, 0, 4898288851081953280, 140737235119664, 0, 0, 4294969344, 0, 72058143793676288, 0, 0, 140737326101420, 562962838323220, 45729780788658, 4294967296, 72058139498840072, 72058139498905608, 122509647347719, 563035852767292...} e = 0xbcf0f8 base = {e_id = 2, e_name = {bv_len = 140737018603856, bv_val = 0x8000 <Address 0x8000 out of bounds>}, e_nname = {bv_len = 16, bv_val = 0x7fffe4103ed0 "ou=users,dc=test"}, e_attrs = 0x44471d, e_ocflags = 5254706, e_bv = {bv_len = 0, bv_val = 0x10000 <Address 0x10000 out of bounds>}, e_private = 0x7fffe41033e0} e_root = <value optimized out> matched = 0x0 ei = 0x7fffe41035c0 realbase = {bv_len = 16, bv_val = 0x7fffe4103ed0 "ou=users,dc=test"} mask = <value optimized out> manageDSAit = <value optimized out> tentries = 3 nentries = <value optimized out> idflag = 0 lock = {off = 398968, ndx = 98, gen = 2, mode = DB_LOCK_READ} opinfo = 0x0 ltid = 0x7fffe4102d20 oex = <value optimized out> #7 0x000000000049db2f in overlay_op_walk (op=0x7fffe4002950, rs=0x7ffff0e81a20, which=<value optimized out>, oi=0x89f650, on=0x0) at backover.c:669 rc = 32768 ... -- BOFH excuse #204: Just pick up the phone and give modem connect sounds. "Well you said we should get more lines so we don't have voice lines."

1 0

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 19 Jan '10

19 Jan '10

* alexs(a)ulgsm.ru <alexs(a)ulgsm.ru> [2009-11-05 07:43:02 +0000]: New OpenLdapd 2.4.21 on new freebsd 8.0 is still crashed. I can make a public test server, to let some one check my configs and see faults. Also intresting have any body same failures? > Full_Name: Aleksey > Version: 2.4.19 > OS: Freebsd7.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.93.136.26) > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > Freebsd 7.2 amd64 > Slapd built with the "-g" flag and install with the make install STRIP="" > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > In slapd config added using hdb as backend and indexes. > > Testing database consist of 1000 users accounts with minimum attributes. > > On stress test load slapd Segmentation fault in 10-30 sec. > > > #ldd /usr/local/libexec/slapd > /usr/local/libexec/slapd: > libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) > liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) > libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) > libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000) > libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000) > libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000) > libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000) > libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000) > libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000) > libthr.so.3 => /lib/libthr.so.3 (0x8014dd000) > libc.so.7 => /lib/libc.so.7 (0x8015f5000) > > > > > #gdb /usr/local/libexec/slapd > (gdb) run -d 0 > Starting program: /usr/local/libexec/slapd -d 0 > [New LWP 100311] > [New Thread 0x801a020b0 (LWP 100311)] > [New Thread 0x801a02880 (LWP 100073)] > [New Thread 0x8034040b0 (LWP 100076)] > [New Thread 0x803404240 (LWP 100077)] > [New Thread 0x8034043d0 (LWP 100078)] > [New Thread 0x803404560 (LWP 100116)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x803404560 (LWP 100116)] > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address > 0x7ffffd9f9f38: Bad s. > ) at idl.c:511 > 511 { > (gdb) > (gdb) > (gdb) where > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > address 0x7ffffd9f9f38: dress. > ) at idl.c:511 > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, > txn=0x80352b040, k=0x8069005 > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, > ava=0x7ffffda7a4f0, > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a550, > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at > filterindex.c:581 > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a530, > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at > filterindex.c:581 > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a570, > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, > e=0x7ffffda7a71 tx > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:586 > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:366 > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:217 > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, > arg_v=0x803521000) at connection > .c:1123 > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) > at connection.c:125 > 9 > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > /usr/local/lib/libldap_r-2.4.so. > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > #16 0x0000000000000000 in ?? () > Error accessing memory address 0x7ffffdbfb000: Bad address. -- alexs

1 0

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs