openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#8649) Issue when fetching the backend that will receive the contextCSN when we have glued databases
by elecharny＠gmail.com 28 Apr '17

28 Apr '17

Using a value of 0 for the subs parameter of the select_backend( &backend->be_nsuffix[0], 1 ) function instead of 1 won't help : it would select the local backend. We really need to recurse up to the top level backend slicing the RDN at each round. -- Emmanuel Lecharny Symas.com directory.apache.org

1 0

(ITS#8649) Issue when fetching the backend that will receive the contextCSN when we have glued databases
by elecharny＠apache.org 28 Apr '17

28 Apr '17

Full_Name: Emmanuel L.charny Version: 2.4.45 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (176.154.3.51) When syncrepl is started, it first searches which backend will host the contextCSN. There are two factors in play : - do we have a syncprov overlay - do we have parent backends. If the local DB is a subordinate, then we have to look in its parents to see if one of them has a syncprov overlay. If so, then this backend will be the one receiving the contextCSN. Otherwise, the local DB will. Now, if we have a hierarchy of backends (ie, 3 or more subordinates in a chain), with the syncprov overlay present in an intermediate backend, then the contextCSN will not be attached to it, but to the local DB. This is because the select_backend( &backend->be_nsuffix[0], 1 ) function tries to fetch the top level backend, regardless the presence of the syncprov overlay in intermediary subordinates. IMO, instead of calling select_backend with the parameter 1 (is, subs), we should call it recursively up to the point we reach the top level or we find a backend with the syncprov overlay.

1 0

Re: (ITS#8648) sasl_client_init called concurrently causes issues
by ryan＠nardis.ca 28 Apr '17

28 Apr '17

On Fri, Apr 28, 2017 at 04:43:33AM +0000, ryan(a)openldap.org wrote: >If I'm right about this bug, I suppose the right fix is to wrap sasl_client_init >in a new mutex. ... of course that idea's half-baked, because libldap doesn't *have* mutexes. hmm. I tried cyrus-sasl-2.1.25 and the issue doesn't seem to happen. I'll see if I can isolate the related change.

1 0

(ITS#8648) sasl_client_init called concurrently causes issues
by ryan＠openldap.org 27 Apr '17

27 Apr '17

Full_Name: Ryan Tandy Version: RE24 (66d107e) OS: Debian URL: Submission from: (NULL) (24.68.41.160) Submitted by: ryan Test program uploaded to the FTP site: ftp://ftp.openldap.org/incoming/20170427_rtandy_sasltest.c I have built cyrus-sasl and openldap myself from clean sources in order to rule out issues introduced by Debian patches. My environment is Debian unstable with OpenSSL 1.0.2k. cyrus-sasl master at 04dd838 ./autogen.sh CFLAGS="-g -O0" --with-devrandom=/dev/urandom make sudo make install sudo ldconfig export SASL_PATH=/usr/local/lib/sasl2 openldap RE24 at 66d107e ./configure CFLAGS="-g -O0" --disable-backends --enable-mdb --disable-overlays --with-cyrus-sasl --with-tls=openssl make sudo make STRIP= install sudo ldconfig cat > slapd.conf << 'eof' include servers/slapd/schema/core.schema include servers/slapd/schema/cosine.schema sasl-secprops none authz-regexp uid=(.*),cn=.*,cn=auth ldap:///dc=example,dc=com??sub?(uid=$1) database mdb directory . suffix dc=example,dc=com rootdn cn=root,dc=example,dc=com index objectClass eq eof /usr/local/sbin/slapadd -f slapd.conf << eof dn: dc=example,dc=com objectClass: domain dc: example dn: uid=admin,dc=example,dc=com objectClass: account objectClass: simpleSecurityObject uid: admin userPassword: admin eof /usr/local/libexec/slapd -h ldap://:9000 -f slapd.conf -s0 -dstats # allow PLAIN export LDAPSASL_SECPROPS=none # verify authz-regexp. should return uid=admin,dc=example,dc=com ldapwhoami -H ldap://:9000 -Y PLAIN -U admin -w admin # edit sasltest.c and change defines as needed. remove -DSASL to use simple bind cc -g -DSASL sasltest.c -pthread -llber -lldap -lsasl2 -o sasltest ./sasltest On my system, most runs of ./sasltest result in errors like: rc = -6 (Unknown authentication method) sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed. Aborted With no concurrency (THREADS defined to 1), I see no errors. I believe this is due to sasl_client_init being called from multiple threads concurrently. I suspect the global mech list is getting mucked with. As a proof of concept, I patched libldap to call sasl_client_init during its global init: ftp://ftp.openldap.org/incoming/20170427_rtandy_call-sasl_client_init-in-gl… With this change, I see no errors. If I'm right about this bug, I suppose the right fix is to wrap sasl_client_init in a new mutex. I'll post a patch for review soon.

1 0

Re: (ITS#8646) openldap aborts with ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36
by quanah＠symas.com 27 Apr '17

27 Apr '17

--On Thursday, April 27, 2017 1:01 PM +0000 kavyauk(a)gmail.com wrote: > Full_Name: Kavya U K > Version: 2.4.33 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (72.163.220.19) > > > Our application uses openladp library to LDAP authentication . > > Intermittently application crashes with below back trace . > > backtrace > =================================== ># 0 0x008b1266 in raise () from /lib/libc.so.6 ># 1 0x008b2c31 in abort () from /lib/libc.so.6 ># 2 0x008aa49d in __assert_fail () from /lib/libc.so.6 ># 3 0x00a3e056 in ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36 > > Please let us know how to resolve it As noted by Michael, you're using an ancient, unsupported release. There also is not enough detail here to do anything actionable. If you can reproduce this issue with the current release of OpenLDAP, then please ensure that you are able to provide a backtrace that contains full debugging symbols, as discussed in <http://www.openldap.org/faq/data/cache/59.html>. For now, this ITS will be closed. Please reply to the ITS with the full backtrace information if you can reproduce with the current OpenLDAP release and we will reopen for investigation. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8647) support of weak ciphers according to rfc4513
by quanah＠symas.com 27 Apr '17

27 Apr '17

Hello, Thanks for your report. The IETF is the correct organization to report RFC issues to, rather than the OpenLDAP Foundation. I would suggest you redirect this to them. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

ITS#8647 published: SECURITY: support of weak ciphers according to rfc4513
by openldap-its＠OpenLDAP.org 27 Apr '17

27 Apr '17

Private ITS#8647 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=8647

1 0

Re: (ITS#8646) openldap aborts with ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36
by michael＠stroeder.com 27 Apr '17

27 Apr '17

kavyauk(a)gmail.com wrote: > Version: 2.4.33 Note that release 2.4.33 is 4,5 years old. Many fixes have been applied since then. Do you still experience the same problem with recent release 2.4.44? Ciao, Michael.

1 0

(ITS#8646) openldap aborts with ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36
by kavyauk＠gmail.com 27 Apr '17

27 Apr '17

Full_Name: Kavya U K Version: 2.4.33 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.163.220.19) Our application uses openladp library to LDAP authentication . Intermittently application crashes with below back trace . backtrace =================================== #0 0x008b1266 in raise () from /lib/libc.so.6 #1 0x008b2c31 in abort () from /lib/libc.so.6 #2 0x008aa49d in __assert_fail () from /lib/libc.so.6 #3 0x00a3e056 in ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36 Please let us know how to resolve it

1 0

(ITS#8645) syncrepl configuration error handling
by elecharny＠apache.org 27 Apr '17

27 Apr '17

Full_Name: Emmanuel L.charny Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (176.154.3.51) The parse_syncrepl_line function (syncrepl.c) returns either 0, -1 or 1. 0 is for success, -1 is for a error, 1 seems to be for a warning (ie a parameter is wrongly configured, but then it's ignored). That's ok, except that in the loop where the parameters are parsed, if one of the parameters in {'retry', 'manageDSAit', 'sizelimit', 'timelimit'} is incorect, the following parameters aren't parsed at all, the fuction return 1. At this point, in the caller function add_syncrepl, we have : rc = parse_syncrepl_line( c, si ); if ( rc == 0 ) { ... } if ( rc < 0 ) { Debug( LDAP_DEBUG_ANY, "failed to add syncinfo\n", 0, 0, 0 ); syncinfo_free( si, 0 ); return 1; } else { Debug( LDAP_DEBUG_CONFIG, "Config: ** successfully added syncrepl %s \"%s\"\n", si->si_ridtxt, BER_BVISNULL( &si->si_bindconf.sb_uri ) ? "(null)" : si->si_bindconf.sb_uri.bv_val, 0 ); ... So here, we will have a message indicating syncrepl has properly be initialized, when many parameters might have been ignored. It seems the proper handling of those wrongly initialized parameters should be to do a 'continue' instead of returning 1, and add a warning in logs. Like : ... else if ( !strncasecmp( c->argv[ i ], RETRYSTR "=", STRLENOF( RETRYSTR "=" ) ) ) { if ( parse_syncrepl_retry( c, c->argv[ i ], si ) ) { continue; /* was return 1; } } Or maybe we just want to return -1 in all cases ?

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs