openldap-bugs December 2014

openldap-bugs@openldap.org

24 participants
95 discussions

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

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2014