openldap-bugs March 2016

openldap-bugs@openldap.org

20 participants
38 discussions

(ITS#8389) ldapsearch
by baulin_ss＠mail.ru 16 Mar '16

16 Mar '16

Full_Name: Baulin Sergey Version: unknown OS: Debian8.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.26.169.27) Hello. ldapsearch: @(#) $OpenLDAP: ldapsearch (Jan 17 2016 16:01:42) $ buildd@x86-csail-01:/build/openldap-EAKxYy/openldap-2.4.40+dfsg/debian/build/clients/tools (LDAP library: OpenLDAP 20440) I am running in bash: ldapsearch -H ldap://server -w password -b "DC=domain,DC=local" -s sub -D 'CN=user,DC=domain,DC=local' -x "(objectClass=user)" sn cn mail and it is working but if i am running in bash script: #!/bin/bash BINDDN='CN=user,DC=domain,%3=local' ldapsearch -H ldap://server -w password -b "DC=domain,DC=local" -s sub -D $BINDDN -x "(objectClass=user)" sn cn mail then: ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 525, v1772 Bash variable do not work only for key -D, for other keys bash variable is working

1 0

(ITS#8388) broken schema after replacing objectClass
by lessmian2＠o2.pl 16 Mar '16

16 Mar '16

Full_Name: Tomasz Le&#347;niewski Version: 2.4.44 OS: ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.128.131.1) accidentally i broke my openldap schema when i've changed one of objectClass definitions. For example i have two objectClasses and one is a parent for second: olcObjectClasses: {0}( 1.2.3.4 NAME 'foo' DESC '' SUP top AUXILIARY X-ORIGIN 'user defined' ) olcObjectClasses: {1}( 1.2.3.5 NAME 'bar' DESC '' SUP foo AUXILIARY X-ORIGIN 'user defined' ) I've changed definition of foo - i've delete this object and (my mistake) put it without any number at bottom of all classes: dn: cn=config changetype: modify delete: olcObjectClasses olcObjectClasses: {0} - add: olcObjectClasses olcObjectClasses: ( 1.2.3.4 NAME 'foo' DESC '' SUP top AUXILIARY X-ORIGIN 'user defined' ) So i have now class bar at top of schema and foo at bottom. After restart slapd won't start. Slapcat says: 56d4678f olcObjectClasses: value #5 olcObjectClasses: ObjectClass not found: "foo" 56d4678f config error processing cn=config: olcObjectClasses: ObjectClass not found: "foo" slapcat: bad configuration file! Should slapd allow to make something that could break schema? I thought that there are some constraints that not allow to remove objectClass which is parent for another class.

1 0

Re: (ITS#8384) LDAP Servers in Multi-master configuration locked up and unresponsive
by mhonek＠redhat.com 16 Mar '16

16 Mar '16

Here is the bug filed in Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1317000 On 03/15/2016 03:33 PM, Michael Ströder wrote: > mhonek(a)redhat.com wrote: > > this seems to be a RHEL/CentOS-specific issue. Please contact Red Hat Support. > > I think this ITS ticket may be closed. > > How about adding a link to Red Hat's issue tracker in this ticket? > > Ciao, Michael. > -- Matúš Honěk

1 0

Re: (ITS#8385) Use After Free of struct ldap_common in slap_client_connect
by mkp37215＠gmail.com 15 Mar '16

15 Mar '16

On Mon, Mar 14, 2016 at 8:04 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > The Debian/Ubuntu maintainers are quite aware of the problems with using > GnuTLS, and maintain they cannot use OpenSSL due to licensing issues, > despite the fact every other major distribution uses OpenSSL (except RHEL, > which switched to MozNSS which resulted in much disaster, and is likely > going to switch back to OpenSSL). > > There is no reason you cannot use OpenSSL, regardless of what > Debian/Ubuntu's broken decisions are. > > --Quanah Quanah, thank you for your reply. However, I do not want to engage in a political discussion, particularly on the matter that is beyond my control. It is also out of topic, as the bug discussed here was in libldap code, and not in GnuTLS. I would like to again thank Howard for his work on this bug and coming up with a working fix very quickly. Unless any new issue related to this bug or the fix comes to light, I think we can consider the matter closed. Maciej Puzio

1 0

Re: (ITS#8384) LDAP Servers in Multi-master configuration locked up and unresponsive
by michael＠stroeder.com 15 Mar '16

15 Mar '16

mhonek(a)redhat.com wrote: > this seems to be a RHEL/CentOS-specific issue. Please contact Red Hat Support. > I think this ITS ticket may be closed. How about adding a link to Red Hat's issue tracker in this ticket? Ciao, Michael.

1 0

(ITS#8387) online olcDbConfig change fails with syncprov
by ryan＠openldap.org 14 Mar '16

14 Mar '16

Full_Name: Ryan Tandy Version: 2.4, master OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan Forwarding from a Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816294 Configure a BDB or HDB database with syncprov: dn: olcDatabase={1}hdb,cn=config objectClass: olcHdbConfig olcDbDirectory: data olcSuffix: dc=example,dc=comD%D dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcSyncProvConfig perform some kind of modification to the database (so that a syncprov checkpoint is pending), and perform an online olcDbConfig change that reopens the database. dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcDbConfig olcDbConfig: set_cachesize 1 0 1 Reopening the database fails: 56e76e17 bdb(dc=example,dc=com): BDB4511 Error: closing the transaction region with active transactions 56e76e17 bdb_db_close: database "dc=example,dc=com": close failed: Invalid argument (22) and slapd crashes shortly after, when it tries to syncprov_checkpoint while the database is already gone. What appears to be happening is that "ctx" is different between bdb_reader_get and bdb_reader_flush in this case. During a normal slapd startup and shutdown: (gdb) thread apply all frame Thread 1 (Thread 0x7ffff7fed700 (LWP 21570)): #0 hdb_reader_get (op=0x7fffffffd8d0, env=0xa93fa0, txn=0x7fffffffd610) at cache.c:1666 1666 if ( !ctx ) { (gdb) p ctx $1 = (void *) 0x8b34a0 <ldap_int_main_thrctx> [ ... killall slapd ... ] (gdb) thread apply all frame Thread 1 (Thread 0x7ffff7fed700 (LWP 21570)): #0 hdb_reader_flush (env=0xa93fa0) at cache.c:1643 1643 if ( !ldap_pvt_thread_pool_getkey( ctx, env, &data, NULL ) ) { (gdb) p ctx $2 = (void *) 0x8b34a0 <ldap_int_main_thrctx> In this case, the readers are cleared correctly. Another startup, this time the hdb_db_close is triggered by performing an olcDbConfig change: (gdb) thread apply all frame Thread 1 (Thread 0x7ffff7fed700 (LWP 21624)): #0 hdb_reader_get (op=0x7fffffffd8d0, env=0xa93fa0, txn=0x7fffffffd610) at cache.c:1666 1666 if ( !ctx ) { (gd2929 p ctx $1 = (void *) 0x8b34a0 <ldap_int_main_thrctx> [ ... ldapmodify ... ] (gdb) thread apply all frame Thread 3 (Thread 0x7ffff362e700 (LWP 21633)): #0 hdb_reader_flush (env=0xa93fa0) at cache.c:1643 1643 if ( !ldap_pvt_thread_pool_getkey( ctx, env, &data, NULL ) ) { Thread 2 (Thread 0x7ffff3e2f700 (LWP 21631)): #0 0x00007ffff732d4d3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. Thread 1 (Thread 0x7ffff7fed700 (LWP 21624)): #0 0x00007ffff75f06dd in pthread_join (threadid=140737285125888, thread_return=0x0) at pthread_join.c:90 90 pthread_join.c: No such file or directory. (gdb) p ctx $2 = (void *) 0x7ffff362dbf0 This time we have a different ctx, so the readers are not cleared. This when we get to db->close there is still an active txn. The comment "free up any keys used by the main thread" seems to assume bdb_reader_flush will be called on the main thread only.

1 0

Re: (ITS#8385) Use After Free of struct ldap_common in slap_client_connect
by quanah＠zimbra.com 14 Mar '16

14 Mar '16

--On Tuesday, March 15, 2016 1:34 AM +0000 mkp37215(a)gmail.com wrote: > --089e0139fc98189d9d052e0b902f > Content-Type: text/plain; charset=UTF-8 > > Howard, thank you very much for quickly fixing this issue. My tests show > that the replication is now working fine. > Regarding your recommendation of OpenSSL, that should rather go to > OpenLDAP package maintainers at Ubuntu and Debian. I use what they build > and the choice of the TLS library is not mine. The Debian/Ubuntu maintainers are quite aware of the problems with using GnuTLS, and maintain they cannot use OpenSSL due to licensing issues, despite the fact every other major distribution uses OpenSSL (except RHEL, which switched to MozNSS which resulted in much disaster, and is likely going to switch back to OpenSSL). There is no reason you cannot use OpenSSL, regardless of what Debian/Ubuntu's broken decisions are. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8385) Use After Free of struct ldap_common in slap_client_connect
by mkp37215＠gmail.com 14 Mar '16

14 Mar '16

--089e0139fc98189d9d052e0b902f Content-Type: text/plain; charset=UTF-8 Howard, thank you very much for quickly fixing this issue. My tests show that the replication is now working fine. Regarding your recommendation of OpenSSL, that should rather go to OpenLDAP package maintainers at Ubuntu and Debian. I use what they build and the choice of the TLS library is not mine. --089e0139fc98189d9d052e0b902f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Howard, thank you very much for quickly fixing this i= ssue. My tests show that the replication is now working fine.<br></div>Rega= rding your recommendation of OpenSSL, that should rather go to OpenLDAP pac= kage maintainers at Ubuntu and Debian. I use what they build and the choice= of the TLS library is not mine.<br></div> --089e0139fc98189d9d052e0b902f--

1 0

(ITS#8386) Small LMDB Documentation patch
by philipp.storz＠bareos.com 14 Mar '16

14 Mar '16

Full_Name: Philipp Storz Version: LMDB 0.9.18 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.79.184.234) >From ede152281433d1e0bdc12741923c715360c4664a Mon Sep 17 00:00:00 2001 From: Philipp Storz <philipp.storz(a)bareos.com> Date: Mon, 14 Mar 2016 10:07:35 +0100 Subject: [PATCH] be a bit more precise that mdb_get retrieves data --- libraries/liblmdb/intro.doc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libraries/liblmdb/intro.doc b/libraries/liblmdb/intro.doc index 9fe9c22..2886c20 100644 --- a/libraries/liblmdb/intro.doc +++ b/libraries/liblmdb/intro.doc @@ -51,7 +51,7 @@ databases should only be opened once, by the first transaction in the process. After the first transaction completes, the database handles can freely be used by all subsequent transactions. -Within a transaction, #mdb_get() and #mdb_put(% c can store single +Within a transaction, #mdb_get() can retrieve and #mdb_put() can store single key/value pairs if that is all you need to do (but see \ref Cursors below if you want to do more). -- 2.6.2

1 0

Re: (ITS#8385) Use After Free of struct ldap_common in slap_client_connect
by hyc＠symas.com 12 Mar '16

12 Mar '16

> Thanks for the report. Inspection shows that the issue only exists in > libldap's GnuTLS support. As always, the Project recommends you use OpenSSL. > > It also looks like only the ldo_tls_require_cert field is being used so we can > probably just copy that flag instead of keeping a pointer to the ldap options > structure. > Fixed now in git master. -- -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2016