Re: (ITS#7995) of-by-one error in schema
by leo＠yuriev.ru
--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/serv...
- if "YES" then "+1" at slapd/ad.c:764 is wrong =
https://github.com/leo-yuriev/openldap-lmdb-challenge/blob/2.4-devel/serv...
- 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/serv...
(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--
8 years, 5 months
(ITS#7996) Global initialisation race in ldap_int_initialize
by a.cudbardb＠freeradius.org
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.
8 years, 5 months
Re: (ITS#7995) of-by-one error in schema
by hyc＠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/
8 years, 5 months
(ITS#7995) of-by-one error in schema
by leo＠yuriev.ru
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)
8 years, 5 months
Re: (ITS#7993) proxyauth with saslmech EXTERNAL not working
by dirk.kastens＠uni-osnabrueck.de
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--
8 years, 5 months
Re: (ITS#7991) problem trying to call ldap_set_option
by shupilov＠tut.by
--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--
8 years, 6 months
Fwd: (ITS#7994) [LMDB] Feature Request: Access to current transaction ID.
by dmbarbour＠gmail.com
--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--
8 years, 6 months
Re: (ITS#7994) [LMDB] Feature Request: Access to current transaction ID.
by hyc＠symas.com
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/
8 years, 6 months
Re: (ITS#7993) proxyauth with saslmech EXTERNAL not working
by hyc＠symas.com
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/
8 years, 6 months