April 2017 - openldap-bugs

Re: (ITS#8649) Issue when fetching the backend that will receive the contextCSN when we have glued databases

by hyc＠symas.com

elecharny(a)gmail.com wrote: > Using a function to compute the working backend, it could be something > like : Discussions really belong on the -devel list, not in the ITS. > > void setWorkingBackend( syncinfo_t *syncInfo, Backend *backend ) > { > if ( !syncInfo->si_wbe ) > { > if ( SLAP_GLUE_SUBORDINATE( backend ) && !overlay_is_inst( > backend, "syncprov" ) ) > { > // The backend has a parent backend, fetch it. Note that we > want to get the > // top parent, not one of the intermediary subordinate, > unless one of them > // has a syncprov overlay declared. If the top level backend > // does not have a syncprov overlay declared, then we use > the local DB > // as a working backend. > BackendDB *currentBackend = backend; > struct berval bv; > ber_str2bv( currentBackend->be_nsuffix[0].bv_val, 0, 0, &bv ); > dnParent( &bv, &bv ); > > while ( ( currentBackend = select_backend( &bv, 0 ) ) != NULL ) > { > if ( overlay_is_inst( currentBackend, "syncprov" ) ) > { > syncInfo->si_wbe = currentBackend; > break; > } > > dnParent( &bv, &bv ); > } > > if ( syncInfo->si_wbe == NULL ) > { > syncInfo->si_wbe = backend; > } > } > else > { > syncInfo->si_wbe = backend; > } > > if ( SLAP_SYNC_SUBENTRY( syncInfo->si_wbe ) ) > { > build_new_dn( &syncInfo->si_contextdn, > &syncInfo->si_wbe->be_nsuffix[0], (struct berval *) > &slap_ldapsync_cn_bv, NULL ); > } > else > { > syncInfo->si_contextdn = syncInfo->si_wbe->be_nsuffix[0]; > } > } > } > > > We call it with > > setWorkingBackend( si, be ); > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

6 years, 1 month

1
0
0 / 0

Re: (ITS#8649) Issue when fetching the backend that will receive the contextCSN when we have glued databases

by elecharny＠gmail.com

Using a function to compute the working backend, it could be something like : void setWorkingBackend( syncinfo_t *syncInfo, Backend *backend ) { if ( !syncInfo->si_wbe ) { if ( SLAP_GLUE_SUBORDINATE( backend ) && !overlay_is_inst( backend, "syncprov" ) ) { // The backend has a parent backend, fetch it. Note that we want to get the // top parent, not one of the intermediary subordinate, unless one of them // has a syncprov overlay declared. If the top level backend // does not have a syncprov overlay declared, then we use the local DB // as a working backend. BackendDB *currentBackend = backend; struct berval bv; ber_str2bv( currentBackend->be_nsuffix[0].bv_val, 0, 0, &bv ); dnParent( &bv, &bv ); while ( ( currentBackend = select_backend( &bv, 0 ) ) != NULL ) { if ( overlay_is_inst( currentBackend, "syncprov" ) ) { syncInfo->si_wbe = currentBackend; break; } dnParent( &bv, &bv ); } if ( syncInfo->si_wbe == NULL ) { syncInfo->si_wbe = backend; } } else { syncInfo->si_wbe = backend; } if ( SLAP_SYNC_SUBENTRY( syncInfo->si_wbe ) ) { build_new_dn( &syncInfo->si_contextdn, &syncInfo->si_wbe->be_nsuffix[0], (struct berval *) &slap_ldapsync_cn_bv, NULL ); } else { syncInfo->si_contextdn = syncInfo->si_wbe->be_nsuffix[0]; } } } We call it with setWorkingBackend( si, be ); -- Emmanuel Lecharny Symas.com directory.apache.org

6 years, 1 month

1
0
0 / 0

Re: (ITS#7005) Collision of LDAP calls between Oracle, Curl and OpenLDAP libraries

by quanah＠symas.com

Hello, The issue reported here is not a problem caused by OpenLDAP. It appears to be due to a static LDAP library from Oracle that was compiled in. You would need to raise this issue with Oracle for a resolution. 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>

6 years, 1 month

1
0
0 / 0

Re: (ITS#7888) client configuration---openldap n-way multi-master replication

by quanah＠symas.com

Hello, Usage questions need to be directed to the openldap-technical list, not the ITS system. This ITS will be closed. For help using the list, see: <http://www.openldap.org/lists/mm/listinfo/openldap-technical> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 1 month

1
0
0 / 0

Re: (ITS#8649) Issue when fetching the backend that will receive the contextCSN when we have glued databases

by elecharny＠gmail.com

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

6 years, 1 month

1
0
0 / 0

(ITS#8649) Issue when fetching the backend that will receive the contextCSN when we have glued databases

by elecharny＠apache.org

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.

6 years, 1 month

1
0
0 / 0

Re: (ITS#8648) sasl_client_init called concurrently causes issues

by ryan＠nardis.ca

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.

6 years, 1 month

1
0
0 / 0

(ITS#8648) sasl_client_init called concurrently causes issues

by ryan＠openldap.org

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-... 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.

6 years, 1 month

1
0
0 / 0

Re: (ITS#8646) openldap aborts with ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36

by quanah＠symas.com

--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>

6 years, 1 month

1
0
0 / 0

Re: (ITS#8647) support of weak ciphers according to rfc4513

by quanah＠symas.com

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>

6 years, 1 month

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2017