- openldap-bugs - openldap.org

Re: (ITS#4744) Bug in SASL authzTo validation using an ldap:// rule
by ando＠sys-net.it 11 Nov '06

11 Nov '06

sylvain(a)pilotsystems.net wrote: > Full_Name: Sylvain Viollon > Version: 2.3 > OS: FreeBSD 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.204.228.114) > > > > I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, > having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) > having the following attribute : > > authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) > > He can successfully authenticate, but not become an user listed by the search > (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the > last user returned by the search. > > In source, I read the file 'servers/slapd/saslauthz.c'. The filter > 'sasl_sc_smatch' said if the wanted user is in the search result. In this > function, there is a test : > > if ( sm->match == 1 ) { > sm->match = -1; > return 0; > } > > I have removed the line : > > sm->match = -1; > > Which make the match to fail if there is an entry in the search return after the > good one. Like every DN have to be unique, there is no multiple solution, and > validation would not be discarded for that. I didn't know if it's a good > solution, but it's work. > > As far as I remember, that test is intended to prevent mapping when the search returns more than one entry. This makes perfectly sense, otherwise a SASL identity (or an authorization identity) would be arbitrarily mapped to one of the matching entries. So mapping is intended to succeed if and only if exactly one identity can be resolved. If the behavior you're experiencing is consistent with the above, there is no evidence of a bug in OpenLDAP software. If it's not, please detail. Otherwise, this ITS will be closed. p. Unless Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4744) Bug in SASL authzTo validation using an ldap:// rule
by sylvain＠pilotsystems.net 11 Nov '06

11 Nov '06

Full_Name: Sylvain Viollon Version: 2.3 OS: FreeBSD 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.204.228.114) I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) having the following attribute : authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) He can successfully authenticate, but not become an user listed by the search (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the last user returned by the search. In source, I read the file 'servers/slapd/saslauthz.c'. The filter 'sasl_sc_smatch' said if the wanted user is in the search result. In this function, there is a test : if ( sm->match == 1 ) { sm->match = -1; return 0; } I have removed the line : sm->match = -1; Which make the match to fail if there is an entry in the search return after the good one. Like every DN have to be unique, there is no multiple solution, and validation would not be discarded for that. I didn't know if it's a good solution, but it's work. Openldap 2.2 and 2.4 seems to have the same problem.

1 0

ITS#3755 strict aliasing rules
by hyc＠symas.com 10 Nov '06

10 Nov '06

Compiling current HEAD with gcc 4.1.1 make AC_CFLAGS="-g -fstrict-aliasing -O3 -Wstrict-aliasing" -j3 CC=gcc turned up a few "will break strict-aliasing rules" warnings: libldap/cyrus.c libldap/getdn.c clients/tools/ldapsearch.c servers/slapd/sasl.c I've silenced all of those. Whether the code was actually unsafe before and is safer now is anybody's guess; I was unable to get any of it to misbehave with various combinations of optimization switches. There are warnings about using the BerElementBuffer "might break strict-aliasing rules" which I've chosen to ignore. Since the memory is only actually referenced through the BerElement pointer, whether or not the contents are defined when accessing the BerElementBuffer is irrelevant. (I.e., we never access it that way, so it's moot.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 10 Nov '06

10 Nov '06

michael(a)stroeder.com wrote: > It seems that slapd stops without configuration error message if unknown > attribute types are set for parameter unique_attributes (slapo-unique). It would > be nice if a descriptive message is displayed (like in other cases). > I think this occurs if debug is set to "config" or "-1". However, it would be more appropriate to log configuration errors that result in failures at "any", so that whatever logging is set they show up. For this purpose, many of the current occurrences of LDAP_DEBUG_CONFIG should be turned into (LDAP_DEBUG_CONFIG | LDAP_DEBUG_NONE), so that they show up when caught by tools with default logging (e.g. slaptest(8)), or into LDAP_DEBUG_ANY, so that they show up all times. I'd vote for the latter. Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4743) ldapsearch manpage Project reference
by quanah＠stanford.edu 10 Nov '06

10 Nov '06

Full_Name: Quanah Gibson-Mount Version: 2.3.28/2.3.29 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) The ldapsearch(1) man page was sync'd for the 2.3.28 release, and inadverdently included a reference to the "Projects" file, which is a HEAD specific bit.

1 0

(ITS#4742) parameter unique_attributes and unknown attribute types
by michael＠stroeder.com 10 Nov '06

10 Nov '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.25.247) HI! It seems that slapd stops without configuration error message if unknown attribute types are set for parameter unique_attributes (slapo-unique). It would be nice if a descriptive message is displayed (like in other cases). Ciao, Michael.

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by hyc＠symas.com 09 Nov '06

09 Nov '06

Eric Covener wrote: > On 11/9/06, Howard Chu <hyc(a)symas.com> wrote: >> covener(a)gmail.com wrote: >> > FWIW, Another SDK I'm working with exposes a once-per-process SSL >> > initialization method, that would amount to ldap_pvt_tls_init(); >> >> A fix for this is in HEAD, please test. > > Now working for me on HEAD: > ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, /CA.pem); > ldap_set_option(NULL, LDAP_OPT_X_TLS_CERTFILE, "/cert1.pem"); > ldap_set_option(NULL, LDAP_OPT_X_TLS_KEYTFILE, "/cert1.key"); > > ld1 = ldap_init(h,p); > ldap_set_option(ld1, LDAP_OPT_X_TLS_CERTFILE, "/cert2.pem"); > ldap_set_option(ld1, LDAP_OPT_X_TLS_KEYTFILE, "/cert2.key"); > ldap_set_option(ld1, LDAP_OPT_X_NEW_CTX, &(is_server)); > > ld2 = ldap_init(h,p); > > and connections to ld1 and ld2 send the right client cert over the > wire. Hope this is a resonable API usage -- Much appreciated! > Thanks for the confirmation. The is_server flag only needs to be set non-zero if you are going to be accepting incoming TLS sessions with that context. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com 09 Nov '06

09 Nov '06

On 11/9/06, Howard Chu <hyc(a)symas.com> wrote: > covener(a)gmail.com wrote: > > FWIW, Another SDK I'm working with exposes a once-per-process SSL > > initialization method, that would amount to ldap_pvt_tls_init(); > > A fix for this is in HEAD, please test. Now working for me on HEAD: ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, /CA.pem); ldap_set_option(NULL, LDAP_OPT_X_TLS_CERTFILE, "/cert1.pem"); ldap_set_option(NULL, LDAP_OPT_X_TLS_KEYTFILE, "/cert1.key"); ld1 = ldap_init(h,p); ldap_set_option(ld1, LDAP_OPT_X_TLS_CERTFILE, "/cert2.pem"); ldap_set_option(ld1, LDAP_OPT_X_TLS_KEYTFILE, "/cert2.key"); ldap_set_option(ld1, LDAP_OPT_X_NEW_CTX, &(is_server)); ld2 = ldap_init(h,p); and connections to ld1 and ld2 send the right client cert over the wire. Hope this is a resonable API usage -- Much appreciated! -- Eric Covener covener(a)gmail.com

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by hyc＠symas.com 09 Nov '06

09 Nov '06

covener(a)gmail.com wrote: > FWIW, Another SDK I'm working with exposes a once-per-process SSL > initialization method, that would amount to ldap_pvt_tls_init(); A fix for this is in HEAD, please test. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com 09 Nov '06

09 Nov '06

FWIW, Another SDK I'm working with exposes a once-per-process SSL initialization method, that would amount to ldap_pvt_tls_init();

1 0

(ITS#4739)
by hardimankevin＠yahoo.com 09 Nov '06

09 Nov '06

--0-1558012606-1163097706=:73509 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Apologies for the breach of etiqette. Will change the backend.=0A=0A -k= ph=0A=0A=0A=0A=0A=0A=0A =0A________________________________________________= ____________________________________=0ADo you Yahoo!?=0AEveryone is raving = about the all-new Yahoo! Mail beta.=0Ahttp://new.mail.yahoo.com --0-1558012606-1163097706=:73509 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:arial, helvetica, sans-serif;font-size:1= 0pt"><div>Apologies for the breach of etiqette.  Will change the backe= nd.     -kph </div></div> =0A=0A=0A<hr = size=3D1>Everyone is raving about <a href=3D"http://us.rd.yahoo.com/evt=3D4= 2297/*http://advision.webevents.yahoo.com/mailbeta">the all-new Yahoo! Mail= beta.</a></body></html> --0-1558012606-1163097706=:73509--

1 0

Re: (ITS#4741) ppolicy.c improperly discards return value of check_password() function
by hyc＠symas.com 09 Nov '06

09 Nov '06

lsherida(a)nccs.nasa.gov wrote: > Full_Name: Lee Sheridan > Version: 2.3.27 > OS: Debian GNU/Linux (etch) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.168.13.7) > > > In servers/slapd/overlays/ppolicy.c, check_password_quality function, at > line 530, the value of the 'ok' variable is discarded by unconditionally > assigning it the value LDAP_SUCCESS. > > The variable is the return code of the user-defined check_password() function, > which is assigned at line 522. The next if-then-else block is checking to > see if the module reported an error, at which point 'ok' would be assigned > LDAP_OTHER regardless of what check_password() returned. A superfluous else > block appears after this check, assigning 'ok' to LDAP_SUCCESS. > > It works fine for me if I remove the else block. > > Thanks, A fix has been committed to CVS HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

[Fwd: Re: (ITS#4739) Server crashes every time alias is dereferenced]
by hyc＠symas.com 09 Nov '06

09 Nov '06

This is a multi-part message in MIME format. --------------080602030800020000070003 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit This is the info Kevin sent before. aliases are known to work incorrectly in back-ldbm. back-ldbm has been deprecated since OpenLDAP 2.2 and has been deleted from the source tree for OpenLDAP 2.4. As such, I don't see us taking any action on this bug report. Use back-bdb or back-hdb instead. -------- Original Message -------- Subject: Re: (ITS#4739) Server crashes every time alias is dereferenced Date: Wed, 8 Nov 2006 22:09:51 -0800 (PST) From: Kevin Hardiman <hardimankevin(a)yahoo.com> To: Howard Chu <hyc(a)symas.com> Howard, To answer your initial questions: 1. The aliased entry does exist 2. The backined is ldbm 3. Attached is a sanitized slapd.conf 4. Attached is a sanitized ldif export Here's the output from running slapd (sanitized for sensitive information) without forking (-d 1): > >> dnPrettyNormal: <ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com> <<< dnPrettyNormal: <ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com>, <ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => ldbm_back_search dn2entry_r: dn: "ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" => dn2id( "ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" ) ====> cache_find_entry_ndn2id("ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com"): 16378 (1 tries) <= dn2id 16378 (in cache) => id2entry_r( 16378 ) ====> cache_find_entry_id( 16378 ) "ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com" (found) (1 tries) <= id2entry_r( 16378 ) 0x82d2068 (cache) search_candidates: base="ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" s=2 d=3 => filter_candidates => list_candidates 0xa0 => filter_candidates => dn2idl( "@ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" ) => ldbm_cache_open( "dn2id.dbb", 73, 600 ) <= ldbm_cache_open (cache 0) <= filter_candidates 2 => filter_candidates => list_candidates 0xa1 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 1 candidates <= equality_candidates 1 <= filter_candidates 1 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 0 candidates <= equality_candidates NULL <= equality_candidates 0 <= filter_candidates 0 idl_free: called with NULL pointer => filter_candidates => list_candidates 0xa0 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 4 candidates <= equality_candidates 4 <= filter_candidates 4 => filter_candidates => equality_candidates => ldbm_cache_open( "uid.dbb", 73, 600 ) <= ldbm_cache_open (cache 4) => key_read <= index_read 0 candidates <= equality_candidates NULL <= equality_candidates 0 <= filter_candidates 0 <= list_candidates NULL <= filter_candidates 0 idl_free: called with NULL pointer <= list_candidates 1 <= filter_candidates 1 <= list_candidates 1 <= filter_candidates 1 ====> cache_return_entry_r( 16378 ): returned (0) => id2entry_r( 16400 ) ====> cache_find_entry_id( 16400 ) "uid=test,ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com" (found) (1 tries) <= id2entry_r( 16400 ) 0x82d5580 (cache) dn2entry_r: dn: "ÿÿÐuhH_øP" => dn2id( "ÿÿÐuhH_øP" ) => ldbm_cache_open( "dn2id.dbb", 73, 600 ) <= ldbm_cache_open (cache 0) <= dn2id NOID slapd: dn.c:1148: dnParent: Assertion `( ( ( ( (p[ 0 ]) >= 'a' && (p[ 0 ]) <= 'z' ) || ( (p[ 0 ]) >= 'A' && (p[ 0 ]) <= 'Z' ) ) ) || ( ( (p[ 0 ]) >= '0' && (p[ 0 ]) <= '9' ) ) )' failed. Aborted Let me know if you need anything else. Regards, Kevin Hardiman ----- Original Message ---- From: Howard Chu <hyc(a)symas.com> To: hardimankevin(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Wednesday, November 8, 2006 9:45:27 PM Subject: Re: (ITS#4739) Server crashes every time alias is dereferenced hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > Version: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) > > > Using the very simple alias below, OpenLDAP will crash every time it is > dereferenced: > > dn: uid=test,ou=Users,ou=bladiant,ou=smb,ou=Core Services,dc=example,dc=com > objectClass: alias > objectclass: extensibleObject > uid: test > aliasedObjectName: uid=test,ou=Users,dc=example,dc=com > > This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, both in > the form of provided Mandriva packages. I also have seen a number of references > to this error in previous releases, with no explicit fix. Please advise. Well, considering that no one has reported any such problem during the whole time releases 2.3.6-2.3.27 were published, it's no surprise that there has been no fix yet. There's not enough information here to reproduce the bug. What backend are you using, what other entries are in the database? In particular, does "uid=test,ou=Users,dc=example,dc=com" exist? You should provide a sample slapd.conf and minimal LDIF needed to reproduce the error. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ ------------------------------------------------------------------------ Sponsored Link $200,000 mortgage for $660/mo - 30/15 yr fixed, reduce debt, home equity - Click now for info <http://www.ratemarketplace.com/forms/form.jsp?ADEL=Os4fVJ19lSwzAOc/zMz/CYLq…> -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ --------------080602030800020000070003 Content-Type: application/octet-stream; name="slapd.conf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd.conf" aW5jbHVkZQkvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jb3JlLnNjaGVtYQppbmNsdWRl CS91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2Nvc2luZS5zY2hlbWEKaW5jbHVkZQkvdXNy L3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jb3JiYS5zY2hlbWEgCmluY2x1ZGUJL3Vzci9zaGFy ZS9vcGVubGRhcC9zY2hlbWEvaW5ldG9yZ3BlcnNvbi5zY2hlbWEKaW5jbHVkZQkvdXNyL3No YXJlL29wZW5sZGFwL3NjaGVtYS9qYXZhLnNjaGVtYSAKaW5jbHVkZQkvdXNyL3NoYXJlL29w ZW5sZGFwL3NjaGVtYS9rcmI1LWtkYy5zY2hlbWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5s ZGFwL3NjaGVtYS9rZXJiZXJvc29iamVjdC5zY2hlbWEKaW5jbHVkZQkvdXNyL3NoYXJlL29w ZW5sZGFwL3NjaGVtYS9taXNjLnNjaGVtYQppbmNsdWRlCS91c3Ivc2hhcmUvb3BlbmxkYXAv c2NoZW1hL25pcy5zY2hlbWEKaW5jbHVkZQkvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9v cGVubGRhcC5zY2hlbWEgCmluY2x1ZGUgL3Vzci9zaGFyZS9vcGVubGRhcC9zY2hlbWEvYXV0 b2ZzLnNjaGVtYQppbmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL3NhbWJhLnNj aGVtYQppbmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2tvbGFiLnNjaGVtYQpp bmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2V2b2x1dGlvbnBlcnNvbi5zY2hl bWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jYWxlbmRhci5zY2hlbWEK aW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9zdWRvLnNjaGVtYQppbmNsdWRl IC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2Ruc3pvbmUuc2NoZW1hCmluY2x1ZGUgL3Vz ci9zaGFyZS9vcGVubGRhcC9zY2hlbWEvZGhjcC5zY2hlbWEKaW5jbHVkZQkvZXRjL29wZW5s ZGFwL3NjaGVtYS9sb2NhbC5zY2hlbWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3Nj aGVtYS9tb3ppbGxhQWJQZXJzb25BbHBoYS5zY2hlbWEKaW5jbHVkZSAJL2V0Yy9vcGVubGRh cC9zbGFwZC5hY2Nlc3MuY29uZgoKYWNjZXNzIHRvIGRuLnN1YnRyZWU9ImRjPWV4YW1wbGUs ZGM9Y29tIgogICAgICAgIGJ5IGdyb3VwPSJjbj1SZXBsaWNhdG9yLG91PUdyb3VwLGRjPWV4 YW1wbGUsZGM9Y29tIgogICAgICAgIGJ5IHVzZXJzIHJlYWQKICAgICAgICBieSBhbm9ueW1v dXMgcmVhZAoKbGltaXRzIGdyb3VwPSJjbj1SZXBsaWNhdG9yLG91PUdyb3VwLGRjPWV4YW1w bGUsZGM9Y29tIgogc2l6ZT11bmxpbWl0ZWQKIHRpbWU9dW5saW1pdGVkCnBpZGZpbGUJCS92 YXIvcnVuL2xkYXAvc2xhcGQucGlkCmFyZ3NmaWxlCS92YXIvcnVuL2xkYXAvc2xhcGQuYXJn cwptb2R1bGVwYXRoCS91c3IvbGliL29wZW5sZGFwClRMU1JhbmRGaWxlICAgICAgICAgICAg L2Rldi9yYW5kb20KVExTQ2lwaGVyU3VpdGUgICAgICAgICBISUdIOk1FRElVTTorU1NMdjIK VExTQ2VydGlmaWNhdGVGaWxlICAgICAgL2V0Yy9zc2wvb3BlbmxkYXAvbGRhcGNlcnQucGVt ClRMU0NlcnRpZmljYXRlS2V5RmlsZSAgIC9ldGMvc3NsL29wZW5sZGFwL2xkYXBrZXkucGVt ClRMU0NBQ2VydGlmaWNhdGVQYXRoICAgL2V0Yy9zc2wvb3BlbmxkYXAvClRMU0NBQ2VydGlm aWNhdGVGaWxlICAgIC9ldGMvc3NsL29wZW5sZGFwL2NhY2VydC5wZW0KVExTVmVyaWZ5Q2xp ZW50IHRyeSAjIChbbmV2ZXJdfGFsbG93fHRyeXxkZW1hbmQpCmxvZ2xldmVsIDI2OAphbGxv dyBiaW5kX3YyCnNhc2wtc2VjcHJvcHMgbm9uZQpkYXRhYmFzZQlsZGJtCnN1ZmZpeAkJImRj PWJsYWRpYW50LGRjPWNvbSIKcm9vdGRuCQkiY249S2V2aW4gSGFyZGltYW4sb3U9UGVvcGxl LGRjPWV4YW1wbGUsZGM9Y29tIgpsYXN0bW9kCQlvbgpkaXJlY3RvcnkJL3Zhci9saWIvbGRh cApjaGVja3BvaW50IDI1NiA1CmluZGV4CW9iamVjdENsYXNzLHVpZCx1aWROdW1iZXIsZ2lk TnVtYmVyLG1lbWJlcnVpZAllcQppbmRleAljbixtYWlsLHN1cm5hbWUsZ2l2ZW5uYW1lCQll cSxzdWJpbml0aWFsCiAK --------------080602030800020000070003 Content-Type: application/octet-stream; name="minimal_export.ldif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="minimal_export.ldif" ZG46IG91PVVzZXJzLCBkYz1leGFtcGxlLGRjPWNvbQpvdTogVXNlcnMKb2JqZWN0Q2xhc3M6 IG9yZ2FuaXphdGlvbmFsVW5pdAoKZG46IHVpZD10ZXN0LCBvdT1Vc2VycywgZGM9ZXhhbXBs ZSxkYz1jb20Kc2FtYmFQcmltYXJ5R3JvdXBTSUQ6IFhYWFgKc2FtYmFMTVBhc3N3b3JkOiBY WFhYCmRpc3BsYXlOYW1lOiBLZXZpbiBIYXJkaW1hbgpvYmplY3RDbGFzczogdG9wCm9iamVj dENsYXNzOiBpbmV0T3JnUGVyc29uCm9iamVjdENsYXNzOiBwb3NpeEFjY291bnQKb2JqZWN0 Q2xhc3M6IHNoYWRvd0FjY291bnQKb2JqZWN0Q2xhc3M6IHNhbWJhU2FtQWNjb3VudAp1c2Vy UGFzc3dvcmQ6OiBYWFhYCnNhbWJhTG9nb25UaW1lOiAwCnVpZE51bWJlcjogNTAwCnVpZDog dGVzdApjbjogdGVzdApzYW1iYUxvZ29mZlRpbWU6IDIxNDc0ODM2NDcKc2FtYmFQd2RMYXN0 U2V0OiAxMTYxOTIzMzcwCmxvZ2luU2hlbGw6IC9iaW4vYmFzaApzYW1iYUFjY3RGbGFnczog W1VdCmdpZE51bWJlcjogMTAwCnNhbWJhUHdkTXVzdENoYW5nZTogMTE2NTgxMTM3MApzYW1i YVNJRDogWFhYCnNhbWJhUHdkQ2FuQ2hhbmdlOiAwCnNhbWJhTlRQYXNzd29yZDogWFhYCmdl Y29zOiBLZXZpbiBIYXJkaW1hbgpkZXNjcmlwdGlvbjogS2V2aW4gSGFyZGltYW4KaG9tZURp cmVjdG9yeTogL2hvbWUvdGVzdApzYW1iYUtpY2tvZmZUaW1lOiAyMTQ3NDgzNjQ3CnNuOiBI YXJkaW1hbgoKZG46IG91PUNvcmUgU2VydmljZXMsIGRjPWV4YW1wbGUsZGM9Y29tCm91OiBD b3JlIFNlcnZpY2VzCm9iamVjdENsYXNzOiB0b3AKb2JqZWN0Q2xhc3M6IG9yZ2FuaXphdGlv bmFsVW5pdAoKZG46IG91PXNtYiwgb3U9Q29yZSBTZXJ2aWNlcywgZGM9ZXhhbXBsZSxkYz1j b20Kb3U6IHNtYgpvYmplY3RDbGFzczogdG9wCm9iamVjdENsYXNzOiBvcmdhbml6YXRpb25h bFVuaXQKCmRuOiBvdT1leGFtcGxlLG91PXNtYiwgb3U9Q29yZSBTZXJ2aWNlcywgZGM9ZXhh bXBsZSxkYz1jb20Kb3U6IGV4YW1wbGUKb2JqZWN0Q2xhc3M6IHRvcApvYmplY3RDbGFzczog b3JnYW5pemF0aW9uYWxVbml0Cgpkbjogb3U9VXNlcnMsb3U9ZXhhbXBsZSxvdT1zbWIsIG91 PUNvcmUgU2VydmljZXMsIGRjPWV4YW1wbGUsZGM9Y29tCm91OiBVc2VycwpvYmplY3RDbGFz czogdG9wCm9iamVjdENsYXNzOiBvcmdhbml6YXRpb25hbFVuaXQKCmRuOiB1aWQ9dGVzdCxv dT1Vc2VycyxvdT1leGFtcGxlLG91PXNtYixvdT1Db3JlIFNlcnZpY2VzLGRjPWV4YW1wbGUs ZGM9Y29tCm9iamVjdENsYXNzOiBhbGlhcwpvYmplY3RjbGFzczogZXh0ZW5zaWJsZU9iamVj dAp1aWQ6IHRlc3QKYWxpYXNlZE9iamVjdE5hbWU6IHVpZD10ZXN0LG91PVVzZXJzLGRjPWV4 YW1wbGUsZGM9Y29tCg== --------------080602030800020000070003--

1 0

Re: (ITS#4741) ppolicy.c improperly discards return value of check_password() function
by quanah＠stanford.edu 09 Nov '06

09 Nov '06

--On Thursday, November 09, 2006 2:20 AM +0000 lsherida(a)nccs.nasa.gov wrote: > Full_Name: Lee Sheridan > Version: 2.3.27 > OS: Debian GNU/Linux (etch) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.168.13.7) > > > In servers/slapd/overlays/ppolicy.c, check_password_quality function, at > line 530, the value of the 'ok' variable is discarded by unconditionally > assigning it the value LDAP_SUCCESS. > > The variable is the return code of the user-defined check_password() > function, which is assigned at line 522. The next if-then-else block is > checking to see if the module reported an error, at which point 'ok' > would be assigned LDAP_OTHER regardless of what check_password() > returned. A superfluous else block appears after this check, assigning > 'ok' to LDAP_SUCCESS. > > It works fine for me if I remove the else block. Howard checked in a fix to HEAD for this last night, please test. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by quanah＠stanford.edu 09 Nov '06

09 Nov '06

--On Thursday, November 09, 2006 5:08 PM +0000 hardimankevin(a)yahoo.com wrote: > --0-1753053770-1163092074=:90949 > Content-Type: text/plain; charset=ascii > Content-Transfer-Encoding: quoted-printable > > Buchan,=0A=0ANot sure what to say - I can reproduce this error with the > Man= driva packages and from source (which leads me to believe it has > nothing to= do with the packaging) with a 100% rate. I had sent Howard > Chu an email l= ast night with much more detail; if you'd like me to > forward that I will.= =0A=0A -kph=0A=0A=0A----- Original Message > You should send responses with more detail to the ITS, not to individual people. This allows all developers and other involved to have the full information. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by hardimankevin＠yahoo.com 09 Nov '06

09 Nov '06

--0-1753053770-1163092074=:90949 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Buchan,=0A=0ANot sure what to say - I can reproduce this error with the Man= driva packages and from source (which leads me to believe it has nothing to= do with the packaging) with a 100% rate. I had sent Howard Chu an email l= ast night with much more detail; if you'd like me to forward that I will.= =0A=0A -kph=0A=0A=0A----- Original Message ----=0AFrom: Buchan Milne <bg= milne(a)staff.telkomsa.net>=0ATo: hardimankevin(a)yahoo.com=0ACc: openldap-its@= openldap.org=0ASent: Thursday, November 9, 2006 11:07:10 AM=0ASubject: Re: = (ITS#4739) Server crashes every time alias is dereferenced=0A=0AOn Wednesda= y 08 November 2006 21:18, hardimankevin(a)yahoo.com wrote:=0A> Full_Name: Kev= in Hardiman=0A> Version: 2.3.27=0A> OS: Linux (Mandriva 2007)=0A> URL: ftp:= //ftp.openldap.org/incoming/=0A> Submission from: (NULL) (24.90.130.182)=0A= >=0A>=0A> Using the very simple alias below, OpenLDAP will crash every time= it is=0A> dereferenced:=0A>=0A> dn: uid=3Dtest,ou=3DUsers,ou=3Dbladiant,ou= =3Dsmb,ou=3DCore Services,dc=3Dexample,dc=3Dcom=0A> objectClass: alias=0A> = objectclass: extensibleObject=0A> uid: test=0A> aliasedObjectName: uid=3Dte= st,ou=3DUsers,dc=3Dexample,dc=3Dcom=0A>=0A> This error has been experience = with OpenLDAP releases 2.3.6 and 2.3.27,=0A> both in the form of provided M= andriva packages. I also have seen a number=0A> of references to this erro= r in previous releases, with no explicit fix. =0A> Please advise.=0A=0A=0AC= an't reproduce:=0A=0A$ ldapsearch -h localhost -LLL -s children -a never -= x -b "ou=3DTest =0AAliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom"=0Adn: uid=3D= bgmilne,ou=3DTest Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0AobjectClass:= alias=0AobjectClass: extensibleObject=0Auid: bgmilne=0AaliasedObjectName: = uid=3Dbgmilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0A=0A$ ldapsea= rch -h localhost -LLL -s children -a always -x -b "ou=3DTest =0AAliases,dc= =3Dranger,dc=3Ddnsalias,dc=3Dcom" objectclass=0Adn: uid=3Dbgmilne,ou=3DPeop= le,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0AobjectClass: mailRecipient=0Aobject= Class: person=0AobjectClass: organizationalPerson=0AobjectClass: inetOrgPer= son=0AobjectClass: posixAccount=0AobjectClass: top=0AobjectClass: kerberosS= ecurityObject=0AobjectClass: shadowAccount=0AobjectClass: sambaSamAccount= =0A=0A$ rpm -q openldap-servers=0Aopenldap-servers-2.3.27-1mdv2007.0=0A=0A$= rpm -q openldap-servers --qf "%{PACKAGER}\n"=0ABuchan Milne <bgmilne@mandr= iva.org>=0A=0A=0ARegards,=0ABuchan=0A=0A-- =0ABuchan Milne=0AISP Systems Sp= ecialist - Monitoring/Authentication Team Leader=0AB.Eng,RHCE(8030047890107= 97),LPIC-2(LPI000074592)=0A=0A=0A=0A=0A=0A=0A=0A =0A_______________________= _____________________________________________________________=0ADo you Yaho= o!?=0AEveryone is raving about the all-new Yahoo! Mail beta.=0Ahttp://new.m= ail.yahoo.com --0-1753053770-1163092074=:90949 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:arial, helvetica, sans-serif;font-size:1= 0pt"><div style=3D"font-family: arial,helvetica,sans-serif; font-size: 10pt= ;">Buchan, Not sure what to say - I can reproduce this error with th= e Mandriva packages and from source (which leads me to believe it has nothi= ng to do with the packaging) with a 100% rate.  I had sent Howard Chu = an email last night with much more detail; if you'd like me to forward that= I will.     -kph <div style=3D"font-famil= y: times new roman,new york,times,serif; font-size: 12pt;">----- Original M= essage ---- From: Buchan Milne <bgmilne(a)staff.telkomsa.net> To:= hardimankevin(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Thursday= , November 9, 2006 11:07:10 AM Subject: Re: (ITS#4739) Server crashes ev= ery time alias is dereferenced <div>On Wednesday 08 November 2006 21= :18, hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > V= ersion: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.ope= nldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) >= > > Using the very simple alias below, OpenLDAP will crash eve= ry time it is > dereferenced: > > dn: uid=3Dtest,ou=3DUse= rs,ou=3Dbladiant,ou=3Dsmb,ou=3DCore Services,dc=3Dexample,dc=3Dcom > = objectClass: alias > objectclass: extensibleObject > uid: test<= br>> aliasedObjectName: uid=3Dtest,ou=3DUsers,dc=3Dexample,dc=3Dcom &= gt; > This error has been experience with OpenLDAP releases 2.3.6 and= 2.3.27, > both in the form of provided Mandriva packages. &nbsp= ;I also have seen a number > of references to this error in previous = releases, with no explicit fix. > Please advise. Can't re= produce: $ ldapsearch -h localhost -LLL -s children -a never &n= bsp;-x -b "ou=3DTest Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" dn: uid=3Dbgmilne,ou=3D= Test Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: alias ob= jectClass: extensibleObject uid: bgmilne aliasedObjectName: uid=3Dbgm= ilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom $ ldapsearch -h = localhost -LLL -s children -a always  -x -b "ou=3DTest Aliase= s,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" objectclass dn: uid=3Dbgmilne,ou= =3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: mailRecipient<= br>objectClass: person objectClass: organizationalPerson objectClass:= inetOrgPerson objectClass: posixAccount objectClass: top objectCl= ass: kerberosSecurityObject objectClass: shadowAccount objectClass: s= ambaSamAccount $ rpm -q openldap-servers openldap-servers-2.3.27-= 1mdv2007.0 $ rpm -q openldap-servers --qf "%{PACKAGER}\n" Buchan = Milne <bgmilne(a)mandriva.org> Regards, Buchan -- = Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-= 2(LPI000074592) </div></div> </div></div> =0A=0A<hr size=3D1>Every= one is raving about <a href=3D"http://us.rd.yahoo.com/evt=3D45083/*http://a= dvision.webevents.yahoo.com/mailbeta">the all-new Yahoo! Mail beta.</a></bo= dy></html> --0-1753053770-1163092074=:90949--

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by bgmilne＠staff.telkomsa.net 09 Nov '06

09 Nov '06

--nextPart2681002.ZbxIqWnAlZ Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 08 November 2006 21:18, hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > Version: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) > > > Using the very simple alias below, OpenLDAP will crash every time it is > dereferenced: > > dn: uid=3Dtest,ou=3DUsers,ou=3Dbladiant,ou=3Dsmb,ou=3DCore Services,dc=3D= example,dc=3Dcom > objectClass: alias > objectclass: extensibleObject > uid: test > aliasedObjectName: uid=3Dtest,ou=3DUsers,dc=3Dexample,dc=3Dcom > > This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, > both in the form of provided Mandriva packages. I also have seen a number > of references to this error in previous releases, with no explicit fix.=20 > Please advise. Can't reproduce: $ ldapsearch -h localhost -LLL -s children -a never -x -b "ou=3DTest=20 Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" dn: uid=3Dbgmilne,ou=3DTest Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: alias objectClass: extensibleObject uid: bgmilne aliasedObjectName: uid=3Dbgmilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc= =3Dcom $ ldapsearch -h localhost -LLL -s children -a always -x -b "ou=3DTest=20 Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" objectclass dn: uid=3Dbgmilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: mailRecipient objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: kerberosSecurityObject objectClass: shadowAccount objectClass: sambaSamAccount $ rpm -q openldap-servers openldap-servers-2.3.27-1mdv2007.0 $ rpm -q openldap-servers --qf "%{PACKAGER}\n" Buchan Milne <bgmilne(a)mandriva.org> Regards, Buchan =2D-=20 Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592) --nextPart2681002.ZbxIqWnAlZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFU1IvrJK6UGDSBKcRAhkQAKDCpV5W+plszHrf/GIqkx2yMcTtwQCePs67 JaAwrB9eaYnzEcK7uS41ZEo= =4WpH -----END PGP SIGNATURE----- --nextPart2681002.ZbxIqWnAlZ--

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by hyc＠symas.com 08 Nov '06

08 Nov '06

hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > Version: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) > > > Using the very simple alias below, OpenLDAP will crash every time it is > dereferenced: > > dn: uid=test,ou=Users,ou=bladiant,ou=smb,ou=Core Services,dc=example,dc=com > objectClass: alias > objectclass: extensibleObject > uid: test > aliasedObjectName: uid=test,ou=Users,dc=example,dc=com > > This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, both in > the form of provided Mandriva packages. I also have seen a number of references > to this error in previous releases, with no explicit fix. Please advise. Well, considering that no one has reported any such problem during the whole time releases 2.3.6-2.3.27 were published, it's no surprise that there has been no fix yet. There's not enough information here to reproduce the bug. What backend are you using, what other entries are in the database? In particular, does "uid=test,ou=Users,dc=example,dc=com" exist? You should provide a sample slapd.conf and minimal LDIF needed to reproduce the error. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4741) ppolicy.c improperly discards return value of check_password() function
by lsherida＠nccs.nasa.gov 08 Nov '06

08 Nov '06

Full_Name: Lee Sheridan Version: 2.3.27 OS: Debian GNU/Linux (etch) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.168.13.7) In servers/slapd/overlays/ppolicy.c, check_password_quality function, at line 530, the value of the 'ok' variable is discarded by unconditionally assigning it the value LDAP_SUCCESS. The variable is the return code of the user-defined check_password() function, which is assigned at line 522. The next if-then-else block is checking to see if the module reported an error, at which point 'ok' would be assigned LDAP_OTHER regardless of what check_password() returned. A superfluous else block appears after this check, assigning 'ok' to LDAP_SUCCESS. It works fine for me if I remove the else block. Thanks,

1 0

(ITS#4740) SASL bind assert
by hyc＠OpenLDAP.org 08 Nov '06

08 Nov '06

Full_Name: Howard Chu Version: all < 2.3.29 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc Apparently this bug was discovered by Evgeny Legerov but was not previously reported to anyone on the Project. The bug is now fixed in HEAD and RE23. Performing a SASL Bind with an authcid longer than 255 characters, with a space as the 255th character, will cause the length of the normalized name to be computed incorrectly, failing to take into account the escaping of the space character. (The SASL Bind code truncates all incoming names longer than 255 to exactly 255 characters.) This triggers an assert in libldap because the resulting string length doesn't match what we expected it to be. The fix is in libldap/getdn.c rev 1.134. The MITRE CVE record for this bug is http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5779

1 0

(ITS#4739) Server crashes every time alias is dereferenced
by hardimankevin＠yahoo.com 08 Nov '06

08 Nov '06

Full_Name: Kevin Hardiman Version: 2.3.27 OS: Linux (Mandriva 2007) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.90.130.182) Using the very simple alias below, OpenLDAP will crash every time it is dereferenced: dn: uid=test,ou=Users,ou=bladiant,ou=smb,ou=Core Services,dc=example,dc=com objectClass: alias objectclass: extensibleObject uid: test aliasedObjectName: uid=test,ou=Users,dc=example,dc=com This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, both in the form of provided Mandriva packages. I also have seen a number of references to this error in previous releases, with no explicit fix. Please advise. Kevin Hardiman

1 0

Re: (ITS#4738) hdb livelock
by hyc＠symas.com 07 Nov '06

07 Nov '06

richton(a)nbcs.rutgers.edu wrote: > Please visit > https://www.nbcs.rutgers.edu/~richton/richton-20061107-livelock_2.txt for > an updated backtrace. This one almost looks like it has lock contention, > and a writewaiter assert is notably missing... The trace shows several threads backing off because they think some other thread is about to read the entry from the database. At a guess, none of them is actually going to perform the database read. Most likely a lock is missing here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4738) hdb livelock
by richton＠nbcs.rutgers.edu 07 Nov '06

07 Nov '06

Please visit https://www.nbcs.rutgers.edu/~richton/richton-20061107-livelock_2.txt for an updated backtrace. This one almost looks like it has lock contention, and a writewaiter assert is notably missing... I'm going to rm the bad link, it can only hurt people. On Tue, 7 Nov 2006, Aaron Richton wrote: > Sigh. As may be obvious to anybody unfortunate enough to look at the link, I > seem to have gotten my core files confused. I have a bunch of db_stat -CA > done properly, but the backtrace for this may be lost to the bit bucket. I'll > poke around my systems and see what I can find, but I think it might be > nothing. A syslog of "waiting for 1027 threads to terminate" might be the > only other durable evidence. >

1 0

Re: (ITS#4738) hdb livelock
by richton＠nbcs.rutgers.edu 07 Nov '06

07 Nov '06

Sigh. As may be obvious to anybody unfortunate enough to look at the link, I seem to have gotten my core files confused. I have a bunch of db_stat -CA done properly, but the backtrace for this may be lost to the bit bucket. I'll poke around my systems and see what I can find, but I think it might be nothing. A syslog of "waiting for 1027 threads to terminate" might be the only other durable evidence.

1 0

(ITS#4738) hdb livelock
by richton＠nbcs.rutgers.edu 07 Nov '06

07 Nov '06

Full_Name: Aaron Richton Version: 2.3.28+4720 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061107-livelock.txt Submission from: (NULL) (128.6.31.137) See also ITS#4720, although this is slightly different. hdb livelock (CPU 100% gunned) on 2.3.28 with patch for ITS #4720 (syncprov.c 1.161 -> 1.162 diff). See URL for backtrace and db_stat -CA of the database on threads t@13 and t@16, which (if I'm reading correctly) are the affected ones. I have the db_stat -CA of the other backends saved if I misread, and the core file available if variables are needed. Aside, I know you're looking for RE23 testing, I was kicking the tires of that and about to put it up when this happened. Soon I'll be there, regardless of how this turns out, due to writewaiter concern.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs