openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

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 28 Apr '17

28 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

(ITS#8644) test064-constraint should wait for slapd to start
by ryan＠openldap.org 25 Apr '17

25 Apr '17

Full_Name: Ryan Tandy Version: 2.4.44 OS: Debian URL: Submission from: (NULL) (24.68.41.160) Submitted by: ryan test064-constraint can occasionally fail if ldapadd runs while slapd is still starting up. https://bugs.debian.org/770890 has links to examples. >>>>> Starting test064-constraint for hdb... running defines.sh Starting slapd on TCP/IP port 9011... Adding basic structure... ldapadd failed (255)! >>>>> test064-constraint failed for hdb (exit 255) Other scripts have an ldapsearch loop that waits for slapd to start, and the same should suffice here.

1 0

Re: (ITS#8592) Double free in sssvlv.c
by kevinanties＠gmail.com 24 Apr '17

24 Apr '17

--f403043eddf896760a054de0b265 Content-Type: text/plain; charset=UTF-8 Why this bug is still not fixed? This is a critical bug for those who enable this overlay. On Wed, Feb 22, 2017 at 12:09 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, February 21, 2017 4:20 AM +0000 kevinanties(a)gmail.com wrote: > > --f403045e3462d25e8f054902b3a3 >> Content-Type: text/plain; charset=UTF-8 >> >> I have submitted to ftp/incoming. The filename is >> kevin-170221-sssvlv.patch. >> > > Please carefully read the contribution web page. Your submission is > clearly missing the IPR notice: > > <http://www.openldap.org/devel/contributing.html#notice> > > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > --f403043eddf896760a054de0b265 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Why this bug is still not fixed? This is a critical bug fo= r those who enable this overlay.<br></div><div class=3D"gmail_extra"><br><d= iv class=3D"gmail_quote">On Wed, Feb 22, 2017 at 12:09 AM, Quanah Gibson-Mo= unt <span dir=3D"ltr"><<a href=3D"mailto:quanah@symas.com" target=3D"_bl= ank">quanah(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x">--On Tuesday, February 21, 2017 4:20 AM +0000 <a href=3D"mailto:kevinant= ies(a)gmail.com" target=3D"_blank">kevinanties(a)gmail.com</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --f403045e3462d25e8f054902b3a3<br> Content-Type: text/plain; charset=3DUTF-8<span class=3D""><br> <br> I have submitted to ftp/incoming. The filename is<br> kevin-170221-sssvlv.patch.<br> </span></blockquote> <br> Please carefully read the contribution web page.=C2=A0 Your submission is c= learly missing the IPR notice:<br> <br> <<a href=3D"http://www.openldap.org/devel/contributing.html#notice" rel= =3D"noreferrer" target=3D"_blank">http://www.openldap.org/devel<wbr>/contri= buting.html#notice</a>><div class=3D"HOEnZb"><div class=3D"h5"><br> <br> Regards,<br> Quanah<br> <br> --<br> <br> Quanah Gibson-Mount<br> Product Architect<br> Symas Corporation<br> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:<br> <<a href=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">h= ttp://www.symas.com</a>><br> <br> </div></div></blockquote></div><br></div> --f403043eddf896760a054de0b265--

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