- openldap-bugs - openldap.org

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 10 Dec '14

10 Dec '14

This is a multi-part message in MIME format. --------------090602010509010401080002 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I saw that the master is lost some changes of the my original patch (that was early attached to ITS). Please see attached diff. I think it is a race condition around si_cookieState inside for-loop. --------------090602010509010401080002 Content-Type: text/x-patch; name="its#7968-lost.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its#7968-lost.patch" diff --git a/servers/slapd/syncrepl.c b/servers/slapd/syncrepl.c --- a/servers/slapd/syncrepl.c +++ b/servers/slapd/syncrepl.c @@ -958,15 +958,17 @@ do_syncrep2( ldap_pvt_thread_yield(); } + ldap_pvt_thread_mutex_lock( &si->si_cookieState->cs_mutex ); for ( i =0; i<si->si_cookieState->cs_pnum; i++ ) { if ( sid < si->si_cookieState->cs_psids[i] ) break; if ( si->si_cookieState->cs_psids[i] == sid ) { if ( ber_bvcmp( syncCookie.ctxcsn, &si->si_cookieState->cs_pvals[i] ) <= 0 ) { - ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_pmutex ); bdn.bv_val[bdn.bv_len] = '\0'; Debug( LDAP_DEBUG_SYNC, "do_syncrep2: %s CSN pending, ignoring %s (%s)\n", si->si_ridtxt, syncCookie.ctxcsn->bv_val, bdn.bv_val ); + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex ); + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_pmutex ); ldap_controls_free( rctrls ); rc = 0; goto done; @@ -983,6 +985,7 @@ do_syncrep2( (struct sync_cookie *)&si->si_cookieState->cs_pvals, i, sid, syncCookie.ctxcsn ); } + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex ); assert( punlock < 0 ); punlock = i; } else if (si->si_too_old) { --------------090602010509010401080002--

1 0

Re: (ITS#7995) of-by-one error in schema
by hyc＠symas.com 10 Dec '14

10 Dec '14

Леонид Юрьев wrote: > (2) > But let see to lines 570-575 of mdb-back/attr.c and lines 764-772 of slapd/ad.c: > - does the mdb-value include a NUL byte = > https://github.com/leo-yuriev/openldap-lmdb-challenge/blob/2.4-devel/server… > - if "YES" then "+1" at slapd/ad.c:764 is wrong = > https://github.com/leo-yuriev/openldap-lmdb-challenge/blob/2.4-devel/server… > - but if "NO" then "strcpy()" at slapd/ad.c:772 (and more) is wrong = > https://github.com/leo-yuriev/openldap-lmdb-challenge/blob/2.4-devel/server… And the answer is no, back-mdb/attr.c mdb_ad_get() doesn't store the trailing NUL byte, > diff --git a/servers/slapd/ad.c b/servers/slapd/ad.c > index 246b900..fd60483 100644 > --- a/servers/slapd/ad.c > +++ b/servers/slapd/ad.c > @@ -118,7 +118,7 @@ AttributeDescription * ad_find_tags( > for (ad = type->sat_ad; ad; ad=ad->ad_next) > { > if (ad->ad_tags.bv_len == tags->bv_len && > - !strcasecmp(ad->ad_tags.bv_val, tags->bv_val)) > + !strncasecmp( ad->ad_tags.bv_val, tags->bv_val, ad->ad_tags.bv_len )) > break; > } Unnecessary. > ldap_pvt_thread_mutex_unlock( &type->sat_ad_mutex ); > @@ -742,14 +742,13 @@ int slap_bv2undef_ad( > /* use the appropriate type */ > if ( flags & SLAP_AD_PROXIED ) { > at = slap_schema.si_at_proxied; > - > } else { > at = slap_schema.si_at_undefined; > } > > for( desc = at->sat_ad; desc; desc=desc->ad_next ) { > if( desc->ad_cname.bv_len == bv->bv_len && > - !strcasecmp( desc->ad_cname.bv_val, bv->bv_val ) ) > + !strncasecmp( desc->ad_cname.bv_val, bv->bv_val, desc->ad_cname.bv_len) ) Unnecessary. We've already checked that the two lengths are equal; even if bv->bv_val is non-terminated the compare will stop because desc->ad_cname is terminated. > { > break; > } > @@ -769,7 +768,8 @@ int slap_bv2undef_ad( > > desc->ad_cname.bv_len = bv->bv_len; > desc->ad_cname.bv_val = (char *)(desc+1); > - strcpy(desc->ad_cname.bv_val, bv->bv_val); > + strncpy( desc->ad_cname.bv_val, bv->bv_val, desc->ad_cname.bv_len ) > + [desc->ad_cname.bv_len] = '\0'; This is a valid fix. > > /* canonical to upper case */ > ldap_pvt_str2upper( desc->ad_cname.bv_val ); > @@ -806,9 +806,10 @@ slap_bv2tmp_ad( > slap_sl_mfuncs.bmf_malloc( sizeof(AttributeDescription) + > bv->bv_len + 1, memctx ); > > - ad->ad_cname.bv_val = (char *)(ad+1); > - strncpy( ad->ad_cname.bv_val, bv->bv_val, bv->bv_len+1 ); > ad->ad_cname.bv_len = bv->bv_len; > + ad->ad_cname.bv_val = (char *)(ad+1); > + strncpy( ad->ad_cname.bv_val, bv->bv_val, ad->ad_cname.bv_len) > + [ad->ad_cname.bv_len] = '\0'; > ad->ad_flags = SLAP_DESC_TEMPORARY; > ad->ad_type = slap_schema.si_at_undefined; > Unnecessary. > @@ -887,7 +888,7 @@ an_find( > > for ( ; a->an_name.bv_val; a++ ) { > if ( a->an_name.bv_len != s->bv_len) continue; > - if ( strcasecmp( s->bv_val, a->an_name.bv_val ) == 0 ) { > + if ( strncasecmp( s->bv_val, a->an_name.bv_val, s->bv_len ) == 0 ) { > return( 1 ); > } > } Unnecessary. -- -- 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#7995) of-by-one error in schema
by leo＠yuriev.ru 09 Dec '14

09 Dec '14

--001a11c27ac2dcc7420509ced83c Content-Type: text/plain; charset=UTF-8 2014-12-09 18:57 GMT+03:00 Howard Chu <hyc(a)symas.com>: > leo(a)yuriev.ru wrote: >> >> Full_Name: Leonid Yuriev >> Version: 2.4.40 >> OS: RHEL7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (31.130.36.33) >> >> >> In some cases (presumably when a database contains more attributes than >> defined >> in the scheme) a heap error may be detected at stop of slapd. >> >> Below is the result of attempts to find a bug(s) with Valgrind. >> It is enough to corrupt a malloc's heap! > > > Please provide a test case. Unable to reproduce this on a local database > with commented out schema. I get: > > violino:~/OD/o24/tests> valgrind ../servers/slapd/slapd -Tc -f > /tmp/testr/slapd.1.conf > /tmp/out > ==25499== Memcheck, a memory error detector > ==25499== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==25499== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright > info > ==25499== Command: ../servers/slapd/slapd -Tc -f /tmp/testr/slapd.1.conf > ==25499== > 54871b4f UNKNOWN attributeDescription "HOMEPOSTALADDRESS" inserted. > 54871b4f UNKNOWN attributeDescription "DRINK" inserted. > 54871b4f UNKNOWN attributeDescription "HOMEPHONE" inserted. > 54871b4f UNKNOWN attributeDescription "PAGER" inserted. > ==25499== > ==25499== HEAP SUMMARY: > ==25499== in use at exit: 2,746 bytes in 78 blocks > ==25499== total heap usage: 10,335 allocs, 10,257 frees, 1,649,999 bytes > allocated > ==25499== > ==25499== LEAK SUMMARY: > ==25499== definitely lost: 0 bytes in 0 blocks > ==25499== indirectly lost: 0 bytes in 0 blocks > ==25499== possibly lost: 0 bytes in 0 blocks > ==25499== still reachable: 2,746 bytes in 78 blocks > ==25499== suppressed: 0 bytes in 0 blocks > ==25499== Rerun with --leak-check=full to see details of leaked memory > ==25499== > ==25499== For counts of detected and suppressed errors, rerun with: -v > ==25499== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > > -- > -- 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) Unfortunately it was reproduced only in production-like environment, therefore a testcase or complete info is not available yet. (2) But let see to lines 570-575 of mdb-back/attr.c and lines 764-772 of slapd/ad.c: - does the mdb-value include a NUL byte = https://github.com/leo-yuriev/openldap-lmdb-challenge/blob/2.4-devel/server… - if "YES" then "+1" at slapd/ad.c:764 is wrong = https://github.com/leo-yuriev/openldap-lmdb-challenge/blob/2.4-devel/server… - but if "NO" then "strcpy()" at slapd/ad.c:772 (and more) is wrong = https://github.com/leo-yuriev/openldap-lmdb-challenge/blob/2.4-devel/server… (3) Next, I had added a couple of assert-check into mdb-back/attr.c and right away got "slapcat: attr.c:573: mdb_ad_read: Assertion `bdata.bv_val[bdata.bv_len-1] == 0' failed" diff --git a/servers/slapd/back-mdb/attr.c b/servers/slapd/back-mdb/attr.c index 07b64a6..7979b9d 100644 --- a/servers/slapd/back-mdb/attr.c +++ b/servers/slapd/back-mdb/attr.c @@ -569,6 +569,8 @@ int mdb_ad_read( struct mdb_info *mdb, MDB_txn *txn ) while ( rc == MDB_SUCCESS ) { bdata.bv_len = data.mv_size; bdata.bv_val = data.mv_data; + assert(bdata.bv_len > 0); + assert(bdata.bv_val[bdata.bv_len-1] == 0); ad = NULL; rc = slap_bv2ad( &bdata, &ad, &text ); if ( rc ) { (4) Ok, this is a off-by-one bug. Then I looked for "sizeof(AttributeDescription)" and has found only 3 places in slapd/ad.c ... and fix a few places of str-calls to n-form. Patch is attached, please review it. Leonid. --- The attached files is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned rights and/or interest in this work to any party. I, Leonid Yuriev am authorized by Peter-Service LLC, my employer, to release this work under the following terms. Peter-Service LLC hereby places the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. --001a11c27ac2dcc7420509ced83c Content-Type: text/x-patch; charset=US-ASCII; name="its7995.patch" Content-Disposition: attachment; filename="its7995.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i3hr0n7l0 Y29tbWl0IDkxMzk4NmZjZGI3NGFlMjcyNjk5ZjI0NzA0MzBmMGRjNmM0NTkxM2YKQXV0aG9yOiBM ZW8gWXVyaWV2IDxsZW9AeXVyaWV2LnJ1PgpEYXRlOiAgIDIwMTQtMTItMDkgMjM6Mzg6NDQgKzAz MDAKCiAgICBJVFMjNzk5NSBoZWFwIGNvcnJ1cHRpb24gYW5kIG9mZi1ieS1vbmUgZXJyb3JzIGlu IGF0dHJpYnV0ZS1kZXNjcmlwdGlvbiBoYW5kbGluZy4KCmRpZmYgLS1naXQgYS9zZXJ2ZXJzL3Ns YXBkL2FkLmMgYi9zZXJ2ZXJzL3NsYXBkL2FkLmMKaW5kZXggMjQ2YjkwMC4uZmQ2MDQ4MyAxMDA2 NDQKLS0tIGEvc2VydmVycy9zbGFwZC9hZC5jCisrKyBiL3NlcnZlcnMvc2xhcGQvYWQuYwpAQCAt MTE4LDcgKzExOCw3IEBAIEF0dHJpYnV0ZURlc2NyaXB0aW9uICogYWRfZmluZF90YWdzKAogCWZv ciAoYWQgPSB0eXBlLT5zYXRfYWQ7IGFkOyBhZD1hZC0+YWRfbmV4dCkKIAl7CiAJCWlmIChhZC0+ YWRfdGFncy5idl9sZW4gPT0gdGFncy0+YnZfbGVuICYmCi0JCQkhc3RyY2FzZWNtcChhZC0+YWRf dGFncy5idl92YWwsIHRhZ3MtPmJ2X3ZhbCkpCisJCQkhc3RybmNhc2VjbXAoIGFkLT5hZF90YWdz LmJ2X3ZhbCwgdGFncy0+YnZfdmFsLCBhZC0+YWRfdGFncy5idl9sZW4gKSkKIAkJCWJyZWFrOwog CX0KIAlsZGFwX3B2dF90aHJlYWRfbXV0ZXhfdW5sb2NrKCAmdHlwZS0+c2F0X2FkX211dGV4ICk7 CkBAIC03NDIsMTQgKzc0MiwxMyBAQCBpbnQgc2xhcF9idjJ1bmRlZl9hZCgKIAkvKiB1c2UgdGhl IGFwcHJvcHJpYXRlIHR5cGUgKi8KIAlpZiAoIGZsYWdzICYgU0xBUF9BRF9QUk9YSUVEICkgewog CQlhdCA9IHNsYXBfc2NoZW1hLnNpX2F0X3Byb3hpZWQ7Ci0KIAl9IGVsc2UgewogCQlhdCA9IHNs YXBfc2NoZW1hLnNpX2F0X3VuZGVmaW5lZDsKIAl9CiAKIAlmb3IoIGRlc2MgPSBhdC0+c2F0X2Fk OyBkZXNjOyBkZXNjPWRlc2MtPmFkX25leHQgKSB7CiAJCWlmKCBkZXNjLT5hZF9jbmFtZS5idl9s ZW4gPT0gYnYtPmJ2X2xlbiAmJgotCQkgICAgIXN0cmNhc2VjbXAoIGRlc2MtPmFkX2NuYW1lLmJ2 X3ZhbCwgYnYtPmJ2X3ZhbCApICkKKwkJICAgICFzdHJuY2FzZWNtcCggZGVzYy0+YWRfY25hbWUu YnZfdmFsLCBidi0+YnZfdmFsLCBkZXNjLT5hZF9jbmFtZS5idl9sZW4pICkKIAkJewogCQkgICAg CWJyZWFrOwogCQl9CkBAIC03NjksNyArNzY4LDggQEAgaW50IHNsYXBfYnYydW5kZWZfYWQoCiAK IAkJZGVzYy0+YWRfY25hbWUuYnZfbGVuID0gYnYtPmJ2X2xlbjsKIAkJZGVzYy0+YWRfY25hbWUu YnZfdmFsID0gKGNoYXIgKikoZGVzYysxKTsKLQkJc3RyY3B5KGRlc2MtPmFkX2NuYW1lLmJ2X3Zh bCwgYnYtPmJ2X3ZhbCk7CisJCXN0cm5jcHkoIGRlc2MtPmFkX2NuYW1lLmJ2X3ZhbCwgYnYtPmJ2 X3ZhbCwgZGVzYy0+YWRfY25hbWUuYnZfbGVuICkKKwkJCVtkZXNjLT5hZF9jbmFtZS5idl9sZW5d ID0gJ1wwJzsKIAogCQkvKiBjYW5vbmljYWwgdG8gdXBwZXIgY2FzZSAqLwogCQlsZGFwX3B2dF9z dHIydXBwZXIoIGRlc2MtPmFkX2NuYW1lLmJ2X3ZhbCApOwpAQCAtODA2LDkgKzgwNiwxMCBAQCBz bGFwX2J2MnRtcF9hZCgKIAkJIHNsYXBfc2xfbWZ1bmNzLmJtZl9tYWxsb2MoIHNpemVvZihBdHRy aWJ1dGVEZXNjcmlwdGlvbikgKwogCQkJYnYtPmJ2X2xlbiArIDEsIG1lbWN0eCApOwogCi0JYWQt PmFkX2NuYW1lLmJ2X3ZhbCA9IChjaGFyICopKGFkKzEpOwotCXN0cm5jcHkoIGFkLT5hZF9jbmFt ZS5idl92YWwsIGJ2LT5idl92YWwsIGJ2LT5idl9sZW4rMSApOwogCWFkLT5hZF9jbmFtZS5idl9s ZW4gPSBidi0+YnZfbGVuOworCWFkLT5hZF9jbmFtZS5idl92YWwgPSAoY2hhciAqKShhZCsxKTsK KwlzdHJuY3B5KCBhZC0+YWRfY25hbWUuYnZfdmFsLCBidi0+YnZfdmFsLCBhZC0+YWRfY25hbWUu YnZfbGVuKQorCQlbYWQtPmFkX2NuYW1lLmJ2X2xlbl0gPSAnXDAnOwogCWFkLT5hZF9mbGFncyA9 IFNMQVBfREVTQ19URU1QT1JBUlk7CiAJYWQtPmFkX3R5cGUgPSBzbGFwX3NjaGVtYS5zaV9hdF91 bmRlZmluZWQ7CiAKQEAgLTg4Nyw3ICs4ODgsNyBAQCBhbl9maW5kKAogCiAJZm9yICggOyBhLT5h bl9uYW1lLmJ2X3ZhbDsgYSsrICkgewogCQlpZiAoIGEtPmFuX25hbWUuYnZfbGVuICE9IHMtPmJ2 X2xlbikgY29udGludWU7Ci0JCWlmICggc3RyY2FzZWNtcCggcy0+YnZfdmFsLCBhLT5hbl9uYW1l LmJ2X3ZhbCApID09IDAgKSB7CisJCWlmICggc3RybmNhc2VjbXAoIHMtPmJ2X3ZhbCwgYS0+YW5f bmFtZS5idl92YWwsIHMtPmJ2X2xlbiApID09IDAgKSB7CiAJCQlyZXR1cm4oIDEgKTsKIAkJfQog CX0K --001a11c27ac2dcc7420509ced83c--

1 0

(ITS#7996) Global initialisation race in ldap_int_initialize
by a.cudbardb＠freeradius.org 09 Dec '14

09 Dec '14

Full_Name: Arran Cudbard-Bell Version: 2.4.40 OS: OSX 10.10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.196.165.104) Issue is fully documented here: https://github.com/arr2036/ldapperf/issues/2 As libldap lacks a global initialisation function, the global config struct and other global resources are initialised on the first call to either ldap_create, ldap_get_option or ldap_set_option via a call to ldap_int_initialize. Where multiple threads are spawned and each allocate a new handle using a function that calls ldap_create, the lack of concurrent access protection in ldap_int_initialize causes memory corruption. There are a few ways this could be fixed. One is documented in the issue tracker link above. There are likely better ones. An alternative of fixing this would be to have public functions that can be used to initialise any global resources before creating handles, and to free them explicitly (instead of relying on atexit or a similar mechanism). In terms of writing dynamically loadable/unloadable modules around libldap, the second approach is preferred as any memory allocated on the heap could be cleaned up prior to the module being unloaded.

1 0

Re: (ITS#7995) of-by-one error in schema
by hyc＠symas.com 09 Dec '14

09 Dec '14

leo(a)yuriev.ru wrote: > Full_Name: Leonid Yuriev > Version: 2.4.40 > OS: RHEL7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (31.130.36.33) > > > In some cases (presumably when a database contains more attributes than defined > in the scheme) a heap error may be detected at stop of slapd. > > Below is the result of attempts to find a bug(s) with Valgrind. > It is enough to corrupt a malloc's heap! Please provide a test case. Unable to reproduce this on a local database with commented out schema. I get: violino:~/OD/o24/tests> valgrind ../servers/slapd/slapd -Tc -f /tmp/testr/slapd.1.conf > /tmp/out ==25499== Memcheck, a memory error detector ==25499== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==25499== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info ==25499== Command: ../servers/slapd/slapd -Tc -f /tmp/testr/slapd.1.conf ==25499== 54871b4f UNKNOWN attributeDescription "HOMEPOSTALADDRESS" inserted. 54871b4f UNKNOWN attributeDescription "DRINK" inserted. 54871b4f UNKNOWN attributeDescription "HOMEPHONE" inserted. 54871b4f UNKNOWN attributeDescription "PAGER" inserted. ==25499== ==25499== HEAP SUMMARY: ==25499== in use at exit: 2,746 bytes in 78 blocks ==25499== total heap usage: 10,335 allocs, 10,257 frees, 1,649,999 bytes allocated ==25499== ==25499== LEAK SUMMARY: ==25499== definitely lost: 0 bytes in 0 blocks ==25499== indirectly lost: 0 bytes in 0 blocks ==25499== possibly lost: 0 bytes in 0 blocks ==25499== still reachable: 2,746 bytes in 78 blocks ==25499== suppressed: 0 bytes in 0 blocks ==25499== Rerun with --leak-check=full to see details of leaked memory ==25499== ==25499== For counts of detected and suppressed errors, rerun with: -v ==25499== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) -- -- 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#7995) of-by-one error in schema
by leo＠yuriev.ru 09 Dec '14

09 Dec '14

Full_Name: Leonid Yuriev Version: 2.4.40 OS: RHEL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.130.36.33) In some cases (presumably when a database contains more attributes than defined in the scheme) a heap error may be detected at stop of slapd. Below is the result of attempts to find a bug(s) with Valgrind. It is enough to corrupt a malloc's heap! ==29701== Invalid write of size 1 ==29701== at 0x4A089AF: strcpy (vg_replace_strmem.c:458) ==29701== by 0x45ECC6: slap_bv2undef_ad (ad.c:772) ==29701== by 0x4C3649: mdb_ad_read (attr.c:575) ==29701== by 0x4949D7: mdb_db_open (init.c:278) ==29701== by 0x482D86: over_db_open (backover.c:149) ==29701== by 0x42DA58: backend_startup_one (backend.c:224) ==29701== by 0x42DD22: backend_startup (backend.c:325) ==29701== by 0x44ABB0: slap_startup (init.c:219) ==29701== by 0x406C55: main (main.c:988) ==29701== Address 0x57d9187 is 0 bytes after a block of size 71 alloc'd ==29701== at 0x4A0720A: malloc (vg_replace_malloc.c:296) ==29701== by 0x549A18: ber_memalloc_x (memory.c:228) ==29701== by 0x43901A: ch_malloc (ch_malloc.c:54) =979701== by 0x45EC93: slap_bv2undef_ad (ad.c:764) ==29701== by 0x4C3649: mdb_ad_read (attr.c:575) ==29701== by 0x4949D7: mdb_db_open (init.c:278) ==29701== by 0x482D86: over_db_open (backover.c:149) ==29701== by 0x42DA58: backend_startup_one (backend.c:224) ==29701== by 0x42DD22: backend_startup (backend.c:325) ==29701== by 0x44ABB0: slap_startup (init.c:219) ==29701== by 0x406C55: main (main.c:988) ==29701== ==29701== Invalid read of size 1 ==29701== at 0x53BE9F: ldap_pvt_str2upper (string.c:116) ==29701== by 0x45ECCF: slap_bv2undef_ad (ad.c:775) ==29701== by 0x4C3649: mdb_ad_read (attr.c:575) ==29701== by 0x4949D7: mdb_db_open (init.c:278) ==29701== by 0x482D86: over_db_open (backover.c:149) ==29701== by 0x42DA58: backend_startup_one (backend.c:224) ==291%1== by 0x42DD22: backend_startup (backend.c:325) ==29701== by 0x44ABB0: slap_startup (init.c:219) ==29701== by 0x406C55: main (main.c:988) ==29701== Address 0x57d9187 is 0 bytes after a block of size 71 alloc'd ==29701== at 0x4A0720A: malloc (vg_replace_malloc.c:296) ==29701== by 0x549A18: ber_memalloc_x (memory.c:228) ==29701== by 0x43901A: ch_malloc (ch_malloc.c:54) ==29701== by 0x45EC93: slap_bv2undef_ad (ad.c:764) ==29701== by 0x4C3649: mdb_ad_read (attr.c:575) ==29701== by 0x4949D7: mdb_db_open (init.c:278) ==29701== by 0x482D86: over_db_open (backover.c:149) ==29701== by 0x42DA58: backend_startup_one (backend.c:224) ==29701== by 0x42DD22: backend_startup (backend.c:325) ==29701== by 0x44ABB0: slap_startup (init.c:219) ==29703D%3= by 0x406C55: main (main.c:988) ==29701== Invalid read of size 1 ==29701== at 0x30E184812C: vfprintf (in /lib64/libc-2.12.so) ==29701== by 0x30E186FA51: vsnprintf (in /lib64/libc-2.12.so) ==29701== by 0x5498DA: lutil_debug (debug.c:67) ==29701== by 0x45ED34: slap_bv2undef_a(a8ad.c:785) ==29701== by 0x4C3649: mdb_ad_read (attr.c:575) ==29701== by 0x4949D7: mdb_db_open (init.c:278) ==29701== by 0x482D86: over_db_open (backover.c:149) ==29701== by 0x42DA58: backend_startup_one (backend.c:224) ==29701== by 0x42DD22: backend_startup (backend.c:325) ==29701== by 0x44ABB0: slap_startup (init.c:219) ==29701== by 0x406C55: main (main.c:988) ==29701== Address 0x57d9187 is 0 bytes after a block of size 71 alloc'd ==29701== at 0x4A0720A: malloc (vg_replace_malloc.c:296) ==29701== by 0x549A18: ber_memalloc_x (memory.c:228) ==29701== by 0x43901A: ch_malloc (ch_malloc.c:54) ==29701== by 0x45EC93: slap_bv2undef_ad (ad.c:764) ==29701== by 0x4C3649: mdb_ad_read (attr.c:575) ==29701== by 0x4949D7: mdb_db_open (init.c:278) ==29701== by 0x482D86: over_db_open (backover.c:149) ==29701== by 0x42DA58: backend_startup_one (backend.c:224) ==29701== by 0x42DD22: backend_startup (backend.c:325) ==29701== by 0x44ABB0: slap_startup (init.c:219) ==29701== by 0x406C55: main (main.c:988)

1 0

Re: (ITS#7993) proxyauth with saslmech EXTERNAL not working
by dirk.kastens＠uni-osnabrueck.de 09 Dec '14

09 Dec '14

This is a cryptographically signed message in MIME format. --------------ms060703010908070300060600 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I like to reopen the case. Meanwhile I compiled openldap myself (under RedHat SL 7.0). At first, I compiled openldap-2.4.40. I configured ldap as a replica=20 server. It connects with saslmech EXTERNAL to the master server. When I configure idassert-bind with saslmech EXTERNAL and try to change=20 an entry, ldapmodify fails with ldap_modify: Other (e.g., implementation specific) error (80) slapd.conf logs the message: --------------------------- send_ldap_result:=20 referral=3D"ldap://ldap-master.rz.uni-osnabrueck.de/uid=3Dxmuster,ou=3Dpe= ople,dc=3Duni-osnabrueck,dc=3Dde" >>> dnPrettyNormal: <uid=3Dxmuster,ou=3Dpeople,dc=3Duni-osnabrueck,dc=3D= de> <<< dnPrettyNormal: <uid=3Dxmuster,ou=3Dpeople,dc=3Duni-osnabrueck,dc=3Dd= e>,=20 <uid=3Dxmuster,ou=3Dpeople,dc=3Duni-osnabrueck,dc=3Dde> conn=3D1000 op=3D1 ldap_chain_op:=20 ref=3D"ldap://ldap-master.rz.uni-osnabrueck.de/uid=3Dxmuster,ou=3Dpeople,= dc=3Duni-osnabrueck,dc=3Dde"=20 -> "ldap://ldap-master.rz.uni-osnabrueck.de" conn=3D1000 op=3D1 ldap_chain_op:=20 ref=3D"ldap://ldap-master.rz.uni-osnabrueck.de/uid=3Dxmuster,ou=3Dpeople,= dc=3Duni-osnabrueck,dc=3Dde":=20 URI=3D"ldap://ldap-master.rz.uni-osnabrueck.de" found in cache =3D>ldap_back_getconn: conn=3D1000 op=3D1: lc=3D0x7faca820bc70 inserted r= efcnt=3D1=20 rc=3D0 Error: ldap_back_is_proxy_authz returned 0, misconfigured URI? send_ldap_result: conn=3D1000 op=3D1 p=3D3 send_ldap_result: err=3D80 matched=3D"" text=3D"misconfigured URI?" send_ldap_result: conn=3D1000 op=3D1 p=3D3 send_ldap_result: err=3D80 matched=3D"" text=3D"" send_ldap_response: msgid=3D2 tag=3D103 err=3D80 --------------------------- Then I compiled openldap-2.4.26 and used the same configuration. The=20 modify with saslmech EXTERNAL succeeded: --------------------------- send_ldap_result: conn=3D1001 op=3D1 p=3D3 send_ldap_result: err=3D10 matched=3D"" text=3D"" send_ldap_result:=20 referral=3D"ldap://ldap-master.rz.uni-osnabrueck.de/uid=3Dxmuster,ou=3Dpe= ople,dc=3Duni-osnabrueck,dc=3Dde" >>> dnPrettyNormal: <uid=3Dxmuster,ou=3Dpeople,dc=3Duni-osnabrueck,dc=3D= de> <<< dnPrettyNormal: <uid=3Dxmuster,ou=3Dpeople,dc=3Duni-osnabrueck,dc=3Dd= e>,=20 <uid=3Dxmuster,ou=3Dpeople,dc=3Duni-osnabrueck,dc=3Dde> conn=3D1001 op=3D1 ldap_chain_op:=20 ref=3D"ldap://ldap-master.rz.uni-osnabrueck.de/uid=3Dxmuster,ou=3Dpeople,= dc=3Duni-osnabrueck,dc=3Dde"=20 -> "ldap://ldap-master.rz.uni-osnabrueck.de" conn=3D1001 op=3D1 ldap_chain_op:=20 ref=3D"ldap://ldap-master.rz.uni-osnabrueck.de/uid=3Dxmuster,ou=3Dpeople,= dc=3Duni-osnabrueck,dc=3Dde":=20 URI=3D"ldap://ldap-master.rz.uni-osnabrueck.de" found in cache =3D>ldap_back_getconn: conn=3D1001 op=3D1: lc=3D0x7f4f201fe6f0 inserted r= efcnt=3D1=20 rc=3D0 send_ldap_result: conn=3D1001 op=3D1 p=3D3 send_ldap_result: err=3D0 matched=3D"" text=3D"" send_ldap_response: msgid=3D2 tag=3D103 err=3D0 --------------------------- With a quick look I found out, that the function ldap_back_dobind_int in = server/slapd/back-ldap/bind.c differs. In 2.4.26 you have: --------------------------- if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( &bindcred ) ) { /* if we got here, it shouldn't return result */= rc =3D ldap_back_is_proxy_authz( op, rs, LDAP_BACK_DONTSEND, &binddn, &bindcred )= ; assert( rc =3D=3D 1 ); } rc =3D ldap_back_proxy_authz_bind( lc, op, rs, sendok,=20 &binddn, &bindcred ); goto done; } --------------------------- while in 2.4.40 there is: --------------------------- if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY(=20 &bindcred ) ) { /* if we got here, it shouldn't return result */= rc =3D ldap_back_is_proxy_authz( op, rs, LDAP_BACK_DONTSEND, &binddn, &bindcred )= ; if ( rc !=3D 1 ) { Debug( LDAP_DEBUG_ANY, "Error:=20 ldap_back_is_proxy_authz " "returned %d, misconfigured=20 URI?\n", rc, 0, 0 ); rs->sr_err =3D LDAP_OTHER; rs->sr_text =3D "misconfigured URI?"; LDAP_BACK_CONN_ISBOUND_CLEAR( lc ); if ( sendok & LDAP_BACK_SENDERR ) { send_ldap_result( op, rs ); } goto done; } rc =3D ldap_back_proxy_authz_bind( lc, op, rs, sendok,=20 &binddn, &bindcred ); goto done; } --------------------------- This is where the error message comes from ("misconfigured URI?") --=20 Regards, Dirk Kastens Universitaet Osnabrueck, Rechenzentrum (Computer Center) Albrechtstr. 28, 49069 Osnabrueck, Germany Tel.: +49-541-969-2347, FAX: -2470 --------------ms060703010908070300060600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJDCC BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U 1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6 fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869 080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX 3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFcDCCBFigAwIBAgIHF6QkfFey qDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MB4XDTE0MDUyNzE0NTMzM1oXDTE5MDcwOTIzNTkwMFowgZExCzAJBgNVBAYTAkRFMSAwHgYD VQQKExdVbml2ZXJzaXRhZXQgT3NuYWJydWVjazEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEj MCEGA1UEAxMaVW5pLU9zbmFicnVlY2sgUlotQ0EgRy0wMDIxIzAhBgkqhkiG9w0BCQEWFGNh QHVuaS1vc25hYnJ1ZWNrLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApLZx V6i214uWBb3c16AMckkujPKMXxl9Z4XsEIhrA47tG5YL9upeUrj+duDcrbEQvphvSXJFveVk LK1JMANHJuu/Wa32Bc8IRljYBqhaKMTGRO1q5L6jkMBDwBwenozhlGAaqG+8Cy+qcFoUaoWB RCH2++t5FtXyS1/1GKhWu7yQxCblFul7VXvnLKyaNlOaTalREXb9pQk2N31+rrOgwkbogxc2 z30gQAJXeJ2Ra0SlReqINMmcDd4lfluXjBpFmiJa4xHhQIVJpW2vF8dbqmeKqxIoYziBh78N GaqMSC8IbDPbCM3qaDaGUWKccgb/SKZvrNTLU+jcW66yGi1YPwIDAQABo4ICATCCAf0wEgYD VR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAowCDAGBgRVHSAAMB0G A1UdDgQWBBSqH9h3FW6Z5F+Q1uxjJk4Z6mcUUDAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp 9/EKcD7eZDAfBgNVHREEGDAWgRRjYUB1bmktb3NuYWJydWVjay5kZTCBiAYDVR0fBIGAMH4w PaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9j YWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHKMIHHMDMGCCsGAQUFBzABhidodHRw Oi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1AwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEApVPS1rUMH9oWu02nJHDV C7jF74wUYbzFaX1ULtkEGXK0MV2HyR8kZ3t19qcmEzgo/eaYv5+OE/nMnNHWUH/ybTN3bQFF K4+L+42SwRkSnyXVQsb38NsUknpDAlUeR9+jv5rkhIF5u+sRIXSB1lzoohtVUkYsC50UO1L4 bWchK7DE++22NDiTgtoFWwC1nn2wt8FYTB4IIbCOogEI6fFXIHZkG6BlLiYmPFmbNfPwNJpv 25g87P0SXpQR1uxSv4giL6o6XWCDJpnCEA4+029ZYLZG0e1bSzk4wI+ho08oxNs8B7NPlH2p jOpq40pZwvVw5rp2nu3W5CaDxgHdxXBX5DCCBYcwggRvoAMCAQICBxWm3SXtmbEwDQYJKoZI hvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMSAwHgYDVQQKExdVbml2ZXJzaXRhZXQgT3NuYWJy dWVjazEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEjMCEGA1UEAxMaVW5pLU9zbmFicnVlY2sg UlotQ0EgRy0wMDIxIzAhBgkqhkiG9w0BCQEWFGNhQHVuaS1vc25hYnJ1ZWNrLmRlMB4XDTEz MDUwNjA3NDUyNVoXDTE2MDUwNTA3NDUyNVowXjELMAkGA1UEBhMCREUxIDAeBgNVBAoTF1Vu aXZlcnNpdGFldCBPc25hYnJ1ZWNrMRYwFAYDVQQLEw1SZWNoZW56ZW50cnVtMRUwEwYDVQQD EwxEaXJrIEthc3RlbnMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZObhf0kwV d2daq89+nHsASWUXo8iLb+T9y2N5cmwkVMwAjgtTqjJu+P8jQOxxKaK35pWS5CB1HGiNqLms NOdMVqf1PXdnDANE//wGsMTKwKVjhYlj7PoPSuwAZ4NT8eTf/UR3ViPA64r9qCB8pYBO3L1w n6oMiXdWD8Vd7OVEVzGeMoVYstRyv+wzUAPJotGCd5smxEq+LMTv1HQ6xtZW2le5bMub4uk4 UdACPgCDBGP07sQvM8krM5fNOIbzNRyqD7eERnSMGkounpRkHSwoWUkt1njYUrxk1q4qMDBz xEIx4MPGPw57HN0VQ9z/3eUBjmZi+oqlxkDlHwzcvsH3AgMBAAGjggIUMIICEDAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAgEEAwAwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ4 FSGPMJNnhKKMKGStCzA58jMkmjAfBgNVHSMEGDAWgBSqH9h3FW6Z5F+Q1uxjJk4Z6mcUUDAp BgNVHREEIjAggR5kaXJrLmthc3RlbnNAdW5pLW9zbmFicnVlY2suZGUwgY8GA1UdHwSBhzCB hDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmktb3NuYWJydWVjay1jYS9wdWIv Y3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS91bmktb3NuYWJy dWVjay1jYS9wdWIvY3JsL2NhY3JsLmNybDCBqAYIKwYBBQUHAQEEgZswgZgwSgYIKwYBBQUH MAKGPmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLW9zbmFicnVlY2stY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MEoGCCsGAQUFBzAChj5odHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1v c25hYnJ1ZWNrLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEA pJjFnuZVVSPNqukqAI+ZWWClujzCsBdN1Zq95kik17FqjsB8TSqelmmohw1qBQXq3EnDFmWy R6FuNqYOPjborAEkhwRPmUXDDLvCU02TvwtxFuNJZc0ALz41oR8s8l5PBYoNlpPsYz+tsbKX +15XnsH1ftR/wzqaWPMLfWhG0OnLObeEMb+y5EQPO5kKzf+EdM/JmITWnip03FAtcr9JWq3N p6APfIDoWJ4uM5CyOvnEox41V+2a6PuOKY/bPE9seCOBbduWb15pXYZB7EHWM5Hkp5bLsl7s YtnFH++SCDLyutyLq4LCw1ryt7rLzkUEQ/YZOAqkfifDY6OdW3cRqzGCA/gwggP0AgEBMIGd MIGRMQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVyc2l0YWV0IE9zbmFicnVlY2sxFjAU BgNVBAsTDVJlY2hlbnplbnRydW0xIzAhBgNVBAMTGlVuaS1Pc25hYnJ1ZWNrIFJaLUNBIEct MDAyMSMwIQYJKoZIhvcNAQkBFhRjYUB1bmktb3NuYWJydWVjay5kZQIHFabdJe2ZsTAJBgUr DgMCGgUAoIICLzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x NDEyMDkxMjA4MzNaMCMGCSqGSIb3DQEJBDEWBBS1sK6qItYHdIhly5VEIAAfT5rHjTBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGu BgkrBgEEAYI3EAQxgaAwgZ0wgZExCzAJBgNVBAYTAkRFMSAwHgYDVQQKExdVbml2ZXJzaXRh ZXQgT3NuYWJydWVjazEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEjMCEGA1UEAxMaVW5pLU9z bmFicnVlY2sgUlotQ0EgRy0wMDIxIzAhBgkqhkiG9w0BCQEWFGNhQHVuaS1vc25hYnJ1ZWNr LmRlAgcVpt0l7ZmxMIGwBgsqhkiG9w0BCRACCzGBoKCBnTCBkTELMAkGA1UEBhMCREUxIDAe BgNVBAoTF1VuaXZlcnNpdGFldCBPc25hYnJ1ZWNrMRYwFAYDVQQLEw1SZWNoZW56ZW50cnVt MSMwIQYDVQQDExpVbmktT3NuYWJydWVjayBSWi1DQSBHLTAwMjEjMCEGCSqGSIb3DQEJARYU Y2FAdW5pLW9zbmFicnVlY2suZGUCBxWm3SXtmbEwDQYJKoZIhvcNAQEBBQAEggEAhItoc2cm lCWjQhktZSEUd4TZLSMOptusxxA1zlMP6eMuE4YQOqGikpGQiEtCwKCgLlNHf0HxRotAEGro aJirxRgoq1eL8PbmrCJfuKf+kq1QUaz4ntiOHXNfbTyNyJ57nRRkIjP4zc8MQ2Y8E78/4N5p boiUwH68gT/cLE9RkZNgT0d2CCbD8rHi1PxKF0y8EC/a/KqPHYGlPGZGn2VfJD8ghLoXMfp8 nBaxvxonrj36+XFDt7crAq6EJ8rsClxf5Jwavv+2G0fpJaTdiEsw8v3N+AaAF0Dce6U+1sUT Tc06luAwQmtt5wJCSWM4WeWE+p1VmsrEr3mMmHeDticLRQAAAAAAAA== --------------ms060703010908070300060600--

1 0

Re: (ITS#7991) problem trying to call ldap_set_option
by shupilov＠tut.by 05 Dec '14

05 Dec '14

--Apple-Mail=_549A4F30-9945-4952-B8EB-604E90579662 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, I wasn=E2=80=99t sure that is was a bug but just in the case: = ldap_open (deprecated) works fine with that =E2=80=9Clong=E2=80=9D = address despite of ldap_initialize. Sorry for off topic post. D. On 05 =D0=B4=D0=B5=D0=BA. 2014 =D0=B3., at 22:20, Howard Chu = <openldap-its(a)OpenLDAP.org> wrote: > The OpenLDAP-ITS address is for reporting bugs in OpenLDAP software. > Nothing in your report is indicative of a bug in OpenLDAP. > If you have questions about use of OpenLDAP Software which are > not answered in the documentation, FAQ, and archives, use the > OpenLDAP-technical list (subscription required; instructions here > <http://www.openldap.org/lists/mm/listinfo/openldap-technical>). >=20 > This issue report will be closed. >=20 > p. --Apple-Mail=_549A4F30-9945-4952-B8EB-604E90579662 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space;"><div>Yes, I wasn=E2=80=99t sure that is was a bug = but just in the case: ldap_open (deprecated) works fine with that = =E2=80=9Clong=E2=80=9D address despite of = ldap_initialize.</div><div><br></div><div>Sorry for off topic = post.</div><div><br></div><div>D.</div><br><div><div>On 05 =D0=B4=D0=B5=D0= =BA. 2014 =D0=B3., at 22:20, Howard Chu &lt;<a = href=3D"mailto:openldap-its@OpenLDAP.org">openldap-its(a)OpenLDAP.org</a>&am= p;gt; wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite">The OpenLDAP-ITS address is for reporting bugs in OpenLDAP = software.<br>Nothing in your report is indicative of a bug in = OpenLDAP.<br>If you have questions about use of OpenLDAP Software which = are<br>not answered in the documentation, FAQ, and archives, use = the<br>OpenLDAP-technical list (subscription required; instructions = here<br>&lt;<a = href=3D"http://www.openldap.org/lists/mm/listinfo/openldap-technical&g= t">http://www.openldap.org/lists/mm/listinfo/openldap-technical&gt</a>= ;).<br><br>This issue report will be = closed.<br><br>p.<br></blockquote></div><br></body></html>= --Apple-Mail=_549A4F30-9945-4952-B8EB-604E90579662--

1 0

Fwd: (ITS#7994) [LMDB] Feature Request: Access to current transaction ID.
by dmbarbour＠gmail.com 05 Dec '14

05 Dec '14

--f46d0434c0ba9e39c905097be220 Content-Type: text/plain; charset=UTF-8 I typedef'd MDB_txnid_t at the top of lmdb.h. The patch also tweaks MDB_envinfo. On Fri, Dec 5, 2014 at 11:58 AM, Howard Chu <hyc(a)symas.com> wrote: > > Thanks. There's a slight problem with the patch, your function returns > MDB_txnid_t but that is a private typedef in mdb.c. It is not defined in > lmdb.h, so no one will be able to compile and use this code. > > Easiest change would be to just return size_t, like MDB_envinfo uses. > --f46d0434c0ba9e39c905097be220 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><br><div dir=3D"ltr">I typedef&= #39;d MDB_txnid_t at the top of lmdb.h. The patch also tweaks MDB_envinfo.<= span class=3D""><div><br></div><div><div class=3D"gmail_extra"><div class= =3D"gmail_quote">On Fri, Dec 5, 2014 at 11:58 AM, Howard Chu <span dir=3D"l= tr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a= >></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> Thanks. There's a slight problem with the patch, your function returns = MDB_txnid_t but that is a private typedef in mdb.c. It is not defined in lm= db.h, so no one will be able to compile and use this code.<br> <br> Easiest change would be to just return size_t, like MDB_envinfo uses.<span>= <font color=3D"#888888"><br></font></span></blockquote></div></div></div></= span></div> </div><br></div> --f46d0434c0ba9e39c905097be220--

1 0

Re: (ITS#7994) [LMDB] Feature Request: Access to current transaction ID.
by hyc＠symas.com 05 Dec '14

05 Dec '14

dmbarbour(a)gmail.com wrote: > Full_Name: David Barbour > Version: LMDB 0.9.10 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2602:306:80bb:160:d913:da7:da0f:76b3) > > > As discussed on the list [1], I believe access to the current transaction ID > could be very useful for layering features above LMDB, such as concurrent > writers, read-only to read-write promotion, or serving as an e-tag for polling. > > A patch David-Barbour-141205.patch has been uploaded and includes a disclaimer > to public-domain. > > [1] http://www.openldap.org/lists/openldap-devel/201412/msg00000.html > > Thanks. There's a slight problem with the patch, your function returns MDB_txnid_t but that is a private typedef in mdb.c. It is not defined in lmdb.h, so no one will be able to compile and use this code. Easiest change would be to just return size_t, like MDB_envinfo uses. -- -- 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#7994) [LMDB] Feature Request: Access to current transaction ID.
by dmbarbour＠gmail.com 05 Dec '14

05 Dec '14

Full_Name: David Barbour Version: LMDB 0.9.10 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2602:306:80bb:160:d913:da7:da0f:76b3) As discussed on the list [1], I believe access to the current transaction ID could be very useful for layering features above LMDB, such as concurrent writers, read-only to read-write promotion, or serving as an e-tag for polling. A patch David-Barbour-141205.patch has been uploaded and includes a disclaimer to public-domain. [1] http://www.openldap.org/lists/openldap-devel/201412/msg00000.html

1 0

Re: (ITS#7993) proxyauth with saslmech EXTERNAL not working
by hyc＠symas.com 05 Dec '14

05 Dec '14

dkastens(a)uos.de wrote: > Full_Name: Dirk Kastens > Version: 2.4.39 > OS: RedHat SL 6.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:638:508:3d0:12a:32c6:740c:8971) > > > We installed an ldap cluster with a mirrored master and several replicas on > RedHat SL 6.5 with openldap 2.4.23-34.el6_5.1.x86_64. Write requests to the > replicas are referred to the master server. The chain overlay follows the > referral. It connects with the saslmech EXTERNAL to the master. The master maps > the DN of the certificate to the replica admin. The replica admin has its > authzTo attribute set to the write admin. This way the writing perfectly worked > on our replica servers for all admins that are listed in the authzTo attribute. > Shortly the machines were updated to SL 6.6 with openldap 2.4.39-8.el6.x86_64. > The proxyauth stopped working. Write requests to the replica servers end with > the error > "ldap_modify: Other (e.g., implementationpepecific) error (80)". Without debug output from slapd there's no evidence of an OpenLDAP software bug here. Most likely the TLS library changed between your two versions and you're missing a TLS option now. Regardless, you're using a Red Hat build which contains their own unknown patches to the code. The OpenLDAP Project cannot support these builds since we don't know exactly what they are, but they are known to break OpenLDAP functionality on a routine basis. e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1095976 Ask Red Hat for support on their build. Closing this ITS. -- -- 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#7993) proxyauth with saslmech EXTERNAL not working
by dkastens＠uos.de 05 Dec '14

05 Dec '14

Full_Name: Dirk Kastens Version: 2.4.39 OS: RedHat SL 6.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:508:3d0:12a:32c6:740c:8971) We installed an ldap cluster with a mirrored master and several replicas on RedHat SL 6.5 with openldap 2.4.23-34.el6_5.1.x86_64. Write requests to the replicas are referred to the master server. The chain overlay follows the referral. It connects with the saslmech EXTERNAL to the master. The master maps the DN of the certificate to the replica admin. The replica admin has its authzTo attribute set to the write admin. This way the writing perfectly worked on our replica servers for all admins that are listed in the authzTo attribute. Shortly the machines were updated to SL 6.6 with openldap 2.4.39-8.el6.x86_64. The proxyauth stopped working. Write requests to the replica servers end with the error "ldap_modify: Other (e.g., implementationpepecific) error (80)". I installed another replica under SL 7.0 with openldap-2.4.39-3.el7.x86_64: same result. When I configure the idassertbind attribute to use simple bind with a binddn and credentials, the proxyauth works. This is the chain configuration that doesn't work any longer: olcDbURI: "ldap://ldap-master" olcDbStartTLS: none starttls=no olcDbIDAssertAuthzFrom: {0}* olcDbIDAssertBind: mode=self bindmethod=sasl saslmech=EXTERNAL starttls=yes tls_cert="/etc/openldap/certs/ldap-replica.pem" tls_key="/etc/openldap/certs/ldap-replica.key" tls_cacert="/etc/openldap/cacerts/cacerts.pem" tls_cacertdir="/etc/openldap/cacerts" tls_reqcert=demand This is the configuration that works now: olcDbStartTLS: none starttls=no olcDbURI: "ldap://ldap-master" olcDbIDAssertAuthzFrom: {0}* olcDbIDAssertBind: mode=self bindmethod=simple binddn="cn=proxyuser" credentials="secret" starttls=yes tls_cert="/etc/openldap/certs/ldap-replica.pem" tls_key="/etc/openldap/certs/ldap-replica.key" tls_cacert="/etc/openldap/cacerts/cacerts.pem" tls_cacertdir="/etc/openldap/cacerts" tls_reqcert=demand I looked through the manual pages, but I didn't find a difference between 2.4.23 and 2.4.39. In 2.4.23 we had to load the chain module and now we load the back_ldap module. But that's all. Dirk

1 0

(ITS#7992) lmdb: Windows: assume file paths are UTF-8, encode to UTF-16 for WinAPI and enable compiling when UNICODE is defined
by oskari.timperi＠iki.fi 05 Dec '14

05 Dec '14

Full_Name: Oskari Timperi Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/oskari-timperi-141205.zip Submission from: (NULL) (109.204.204.106) The patches make some changes so that compiling lmdb when UNICODE is defined is possible. This is achieved by using the A-versions of WinApi functions where they are needed. Also use CreateFileW to open files so that one can use exotic characters in paths. The library interface is not modified, but the code makes an assumption that paths passed to lmdb functions are encoded as UTF-8. The UTF-8 encoded paths are encoded to UTF-16 which is then passed to CreateFileW.

1 0

Re: (ITS#7974) LDBM's "laggard reader" flaw still present, in continue of ITS#7904
by h.b.furuseth＠usit.uio.no 04 Dec '14

04 Dec '14

On 12/04/2014 11:31 AM, leo(a)yuriev.ru wrote: > Could you suggest something other instead of "oomkiller"? Don't have a particularly good idea. oom_func, maybe. >> This feature could make it interesting to let readers and writers >> tell each other things: Reserve some unused space in the reader >> table slots for stuff the reader's caller could put there, and >> some space for an impatient writer to leave a note. Could go >> in an independent commit if there is any demand for it though. > > Communications between readers and writers may be interesting, but I > think it is over-engineering in the LMDB context. Yes... I guess I was thinking mostly of the prototype, in case we want to add something like it later. Might be useful to add a void* argument which would be NULL now but could be used later, if needed. -- Hallvard

1 0

Re: (ITS#7974) LDBM's "laggard reader" flaw still present, in continue of ITS#7904
by leo＠yuriev.ru 04 Dec '14

04 Dec '14

Hallvard, thank for your comments. 2014-12-02 14:20 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>: > On 10/23/2014 07:13 AM, leo(a)yuriev.ru wrote: >> >> Subject: [PATCH 1/2] lmdb: ITS#7974 oomkiller feature. >> (...) >> +typedef int (MDB_oomkiller_func)(MDB_env *env, int pid, void* thread_id, >> size_t txn); > > > Some thoughts about this: > > Instead of trusting the return value, it seems safer to re-check > with mdb_reader_pid(). Like mdb_reader_check0() does. Maybe > except on Windows, where file locks from dead processes may > linger for a while until the OS reclaims them. I agree that usign mdb_reader_pid() is a better way. > Don't call it OOMkiller just because that's how you use it. > Others might do something else, like sending a reader a signal > which it interprets as "please wake up and finish your txn". > Or it might decide this process is the one which should give up. Could you suggest something other instead of "oomkiller"? Be noted, the "dreamcatcher" feature has a critical bug, which I has found and made fix while work on ITS#7968 & ITS#7987. Currently we hard testing a new code. So, in a week I plan to update both of the patches. > This feature could make it interesting to let readers and writers > tell each other things: Reserve some unused space in the reader > table slots for stuff the reader's caller could put there, and > some space for an impatient writer to leave a note. Could go > in an independent commit if there is any demand for it though. Communications between readers and writers may be interesting, but I think it is over-engineering in the LMDB context. IMHO the LMDB's code has a lot of technical debt, so it is more usefull to re-implement all of from a scratch, under a rules of perfectly-clean codestyle. May be I will do this, but on a basis and after a release of 1Hippeus - it is a extreme performance engine for zero-copy mesaging in a shared memory, partially like Intel DPDK. Leonid.

1 0

(ITS#7991) problem trying to call ldap_set_option
by shupilov＠tut.by 04 Dec '14

04 Dec '14

Full_Name: Dmitry Shupilov Version: 2.4.39 OS: RHEL 6.5 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.57.254.70) Hello all! It's my first time to post here, so sorry if I will do something wrong :) I have to write shared library which task is to check if the user is correct LDAP user. First of all I prepare env and call ldap_initialize - nothing special here. The ldap_create function sets ld properly (e.g. ld = '0x7fffe40837d0') and in gdb I can read it by (p *ld) or even deeper (p *ld.ldc). But the next function cannot do its job - ldap_set_option failed with "-1" status. I tried to create separate binary which use my shared *.so to do the same job - check a user in LDAP and it works fine: ldap_create assigns "short" address (e.g. 0x602a30). In this case ldap_set_option do what it needs to do. My question is: is the problem of ldap_set_option in that "very long value of address" or is something else? How can I catch the reason of this problem and solve it? BR, Dmitry

1 0

(ITS#7990) (docs) Admin guide: bad link in password policy overlay section
by frederic.poisson＠admin.gmessaging.net 02 Dec '14

02 Dec '14

Full_Name: Frederic POISSON Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.51.12.20) Hello, I'm looking to Password Policy overlay and admin guide 2.4, and i see that Howard CHU has corrected a link (ITS#6264) about "Password Management Issues". But on that link on Symas blog i do not see anything on that subject ? I have also another question about Password policy draft. Does OpenLDAP project already receive a feature request to support the draft in release 10 ? Thanks, Regards,

1 0

Re: (ITS#7974) LDBM's "laggard reader" flaw still present, in continue of ITS#7904
by h.b.furuseth＠usit.uio.no 02 Dec '14

02 Dec '14

On 10/23/2014 07:13 AM, leo(a)yuriev.ru wrote: > Subject: [PATCH 1/2] lmdb: ITS#7974 oomkiller feature. > (...) > +typedef int (MDB_oomkiller_func)(MDB_env *env, int pid, void* thread_id, size_t txn); Some thoughts about this: Instead of trusting the return value, it seems safer to re-check with mdb_reader_pid(). Like mdb_reader_check0() does. Maybe except on Windows, where file locks from dead processes may linger for a while until the OS reclaims them. Don't call it OOMkiller just because that's how you use it. Others might do something else, like sending a reader a signal which it interprets as "please wake up and finish your txn". Or it might decide this process is the one which should give up. This feature could make it interesting to let readers and writers tell each other things: Reserve some unused space in the reader table slots for stuff the reader's caller could put there, and some space for an impatient writer to leave a note. Could go in an independent commit if there is any demand for it though. -- Hallvard

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 02 Dec '14

02 Dec '14

This is a multi-part message in MIME format. --------------090506050608000200000309 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit (1) I can сonfirm once again - the bug is fixed. (2) Previously noted failure "DN index delete failed" caused by another (local) bug. (3) Feature "single write txn" need a minor fix, patch attached. Leonid. --- The attached files is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned rights and/or interest in this work to any party. I, Leonid Yuriev am authorized by Peter-Service LLC, my employer, to release this work under the following terms. Peter-Service LLC hereby places the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. --------------090506050608000200000309 Content-Type: text/x-patch; name="excessive-space-single-write-txn.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="excessive-space-single-write-txn.patch" commit 02094a10018e1ebcae32b920f9d93d300a810f29 Author: Leo Yuriev <leo(a)yuriev.ru> Date: 2014-12-02 14:02:02 +0300 fix excessive space (likely a typo) for single write txn. diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 6e9119d..7587434 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -4589,7 +4589,7 @@ mdb_env_open(MDB_env *env, const char *path, unsigned int flags, mdb_mode_t mode if (!(flags & MDB_RDONLY)) { MDB_txn *txn; int tsize = sizeof(MDB_txn), size = tsize + env->me_maxdbs * - (sizeof(MDB_db)+sizeof(MDB_cursor)+sizeof(unsigned int)+1); + (sizeof(MDB_db)+sizeof(MDB_cursor *)+sizeof(unsigned int)+1); txn = calloc(1, size); if (txn) { txn->mt_dbs = (MDB_db *)((char *)txn + tsize); --------------090506050608000200000309--

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 02 Dec '14

02 Dec '14

> 2014-12-02 6:09 GMT+03:00 Howard Chu <hyc(a)symas.com>: >> Leonid Yuriev wrote: >>> Partially fixed. >>> Patch is for current OPENLDAP_REL_ENG_2_4, but applicable for master. >> >> Thanks, the patch makes sense. But if only partial, what else is still >> crashing? > Stable crash in a 5 seconds after the 4x-cluster resumes from > split-brain condition: > > Program terminated with signal SIGSEGV, Segmentation fault. > #0 __memcpy_sse2_unaligned () at > ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116 > 116 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: Нет такого > файла или каталога. > (gdb) bt > #0 __memcpy_sse2_unaligned () at > ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116 > #1 0x00000000004aee11 in memcpy (__len=<optimised out>, > __src=<optimised out>, __dest=<optimised out>) at > /usr/include/x86_64-linux-gnu/bits/string3.h:51 > #2 mdb_search (op=0x7f16b4ffa7c0, rs=0x7f16b4e697b0) at search.c:993 Seems to be fixed completely. The last SIGSEGV is inducted by a "dreamcatcher" feature (ITS#7974). I already fixed the "dreamcatcher", currently we are re-testing it. Leonid.

1 0

Fwd: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 02 Dec '14

02 Dec '14

2014-12-02 6:09 GMT+03:00 Howard Chu <hyc(a)symas.com>: > Leonid Yuriev wrote: >> >> Partially fixed. >> Patch is for current OPENLDAP_REL_ENG_2_4, but applicable for master. > > > Thanks, the patch makes sense. But if only partial, what else is still > crashing? Stable crash in a 5 seconds after the 4x-cluster resumes from split-brain condition: Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116 116 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: =D0=9D=D0=B5=D1=82= =D1=82=D0=B0=D0=BA=D0=BE=D0=B3=D0=BE =D1=84=D0=B0=D0=B9=D0=BB=D0=B0 =D0=B8=D0=BB=D0=B8 =D0=BA=D0=B0=D1=82=D0=B0= =D0=BB=D0=BE=D0=B3=D0=B0. (gdb) bt #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116 #1 0x00000000004aee11 in memcpy (__len=3D<optimised out>, __src=3D<optimised out>, __dest=3D<optimised out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:51 #2 mdb_search (op=3D0x7f16b4ffa7c0, rs=3D0x7f16b4e697b0) at search.c:993 #3 0x000000000048a52a in overlay_op_walk (op=3Dop@entry=3D0x7f16b4ffa7c0, rs=3D0x7f16b4ff9c40, which=3Dop_search, oi=3D0xc31a30, on=3D<optimised out>= ) at backover.c:676 #4 0x000000000048a681 in over_op_func (op=3D0x7f16b4ffa7c0, rs=3D<optimised out>, which=3D<optimised out>) at backover.c:729 #5 0x000000000047de37 in syncrepl_del_nonpresent (op=3D0x7f16b4ffa7c0, si=3D0xc31490, uuids=3D<optimised out>, m=3D3, sc=3D<optimised out>, sc=3D<optimised out>) at syncrepl.c:3400 #6 0x0000000000481a0e in do_syncrep2 (op=3D0x7f16b4ffa7c0, si=3D0xc31490) at syncrepl.c:1346 #7 0x00000000004839e3 in do_syncrepl (ctx=3D<optimised out>, arg=3D0xc319d0) at syncrepl.c:1550 #8 0x00007f170283ecf2 in ldap_int_thread_pool_wrapper (xpool=3D0xbe4090) at tpool.c:688

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by hyc＠symas.com 02 Dec '14

02 Dec '14

Leonid Yuriev wrote: > Partially fixed. > Patch is for current OPENLDAP_REL_ENG_2_4, but applicable for master. Thanks, the patch makes sense. But if only partial, what else is still crashing? > > Leonid. > > -- > > The attached files is derived from OpenLDAP Software. All of the > modifications > to OpenLDAP Software represented in the following patch(es) were > developed by > Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned > rights > and/or interest in this work to any party. I, Leonid Yuriev am > authorized by > Peter-Service LLC, my employer, to release this work under the following > terms. > > Peter-Service LLC hereby places the following modifications to OpenLDAP > Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or > without attribution and/or other notice. > > > -- -- 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#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 02 Dec '14

02 Dec '14

This is a multi-part message in MIME format. --------------040002050003040401050402 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Partially fixed. Patch is for current OPENLDAP_REL_ENG_2_4, but applicable for master. Leonid. -- The attached files is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned rights and/or interest in this work to any party. I, Leonid Yuriev am authorized by Peter-Service LLC, my employer, to release this work under the following terms. Peter-Service LLC hereby places the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. --------------040002050003040401050402 Content-Type: text/x-patch; name="slapd-syncrepl-locking.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slapd-syncrepl-locking.patch" commit e845cfba8b8c17d291fb810b762e2d2bdb22b016 Author: Leo Yuriev <leo(a)yuriev.ru> Date: 2014-12-01 19:26:08 +0300 ITS#7968: add locking into syncrepl. Mutex must be held even for a read-access of a cookie state, as there may be a race with write in other thread. diff --git a/servers/slapd/syncrepl.c b/servers/slapd/syncrepl.c index caab9f5..eb7bec2 100644 --- a/servers/slapd/syncrepl.c +++ b/servers/slapd/syncrepl.c @@ -926,6 +926,7 @@ do_syncrep2( if ( syncCookie.ctxcsn ) { int i, sid = slap_parse_csn_sid( syncCookie.ctxcsn ); check_syncprov( op, si ); + ldap_pvt_thread_mutex_lock( &si->si_cookieState->cs_mutex ); for ( i =0; i<si->si_cookieState->cs_num; i++ ) { /* new SID */ if ( sid < si->si_cookieState->cs_sids[i] ) @@ -935,15 +936,18 @@ do_syncrep2( bdn.bv_val[bdn.bv_len] = '\0'; Debug( LDAP_DEBUG_SYNC, "do_syncrep2: %s CSN too old, ignoring %s (%s)\n", si->si_ridtxt, syncCookie.ctxcsn->bv_val, bdn.bv_val ); + si->si_too_old = 1; + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex ); ldap_controls_free( rctrls ); rc = 0; - si->si_too_old = 1; goto done; } si->si_too_old = 0; break; } } + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex ); + /* check pending CSNs too */ while ( ldap_pvt_thread_mutex_trylock( &si->si_cookieState->cs_pmutex )) { if ( slapd_shutdown ) { @@ -953,6 +957,8 @@ do_syncrep2( if ( !ldap_pvt_thread_pool_pausecheck( &connection_pool )) ldap_pvt_thread_yield(); } + + ldap_pvt_thread_mutex_lock( &si->si_cookieState->cs_mutex ); for ( i =0; i<si->si_cookieState->cs_pnum; i++ ) { if ( sid < si->si_cookieState->cs_psids[i] ) break; @@ -961,9 +967,10 @@ do_syncrep2( bdn.bv_val[bdn.bv_len] = '\0'; Debug( LDAP_DEBUG_SYNC, "do_syncrep2: %s CSN pending, ignoring %s (%s)\n", si->si_ridtxt, syncCookie.ctxcsn->bv_val, bdn.bv_val ); + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex ); + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_pmutex ); ldap_controls_free( rctrls ); rc = 0; - ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_pmutex ); goto done; } ber_bvreplace( &si->si_cookieState->cs_pvals[i], @@ -978,6 +985,7 @@ do_syncrep2( (struct sync_cookie *)&si->si_cookieState->cs_pvals, i, sid, syncCookie.ctxcsn ); } + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex ); assert( punlock < 0 ); punlock = i; } else if (si->si_too_old) { @@ -1032,6 +1040,7 @@ do_syncrep2( /* on failure, revert pending CSN */ if ( rc != LDAP_SUCCESS ) { int i; + ldap_pvt_thread_mutex_lock( &si->si_cookieState->cs_mutex ); for ( i = 0; i<si->si_cookieState->cs_num; i++ ) { if ( si->si_cookieState->cs_sids[i] == si->si_cookieState->cs_psids[punlock] ) { ber_bvreplace( &si->si_cookieState->cs_pvals[punlock], @@ -1041,6 +1050,7 @@ do_syncrep2( } if ( i == si->si_cookieState->cs_num ) si->si_cookieState->cs_pvals[punlock].bv_val[0] = '\0'; + ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex ); } ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_pmutex ); } --------------040002050003040401050402--

1 0

Re: (ITS#7989) wrong search results "scope one" with mdb backend
by quanah＠zimbra.com 01 Dec '14

01 Dec '14

--On Monday, December 01, 2014 4:04 PM +0000 dab1818(a)gmail.com wrote: > Full_Name: Dmitry Bakshaev > Version: 2.4.38, 2.4.40 > OS: gentoo linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.249.250.7) Duplicate of ITS#7975, fixed in master, closing. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs