openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by quanah＠symas.com 10 May '17

10 May '17

--On Wednesday, May 10, 2017 2:09 PM -0400 Stephen Gallagher <sgallagh(a)redhat.com> wrote: > Sorry, I'm not sure why you're directing this at me? I've not been > involved with this bug at all. Hi Stephen, I'm not sure what you mean by "not involved". You are the one who filed the bug report with us. Here is a direct link for a refresher: <http://www.openldap.org/its/index.cgi/?findid=6798> 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#6798) Mutex starvation on two-level referral for SASL connection
by sgallagh＠redhat.com 10 May '17

10 May '17

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ijumfDLdJ6N1xL1tHwFiTBhCBA9VnmThW Content-Type: multipart/mixed; boundary="rw1j2W5jTxST7ATlUt2I8c5Ena44RM7Vs"; protected-headers="v1" From: Stephen Gallagher <sgallagh(a)redhat.com> To: Quanah Gibson-Mount <quanah(a)symas.com>, openldap-its(a)openldap.org Message-ID: <777f871f-f77e-7041-dc6a-895e1edb56a6(a)redhat.com> Subject: Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection References: <D6162EF94C4315CF6F656712(a)[192.168.1.19]> In-Reply-To: <D6162EF94C4315CF6F656712(a)[192.168.1.19]> --rw1j2W5jTxST7ATlUt2I8c5Ena44RM7Vs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Sorry, I'm not sure why you're directing this at me? I've not been involved with this bug at all. On 05/10/2017 12:56 PM, Quanah Gibson-Mount wrote: > Hi Stephen, > > Would you be able to check and confirm if the fix for ITS#8648 that > has been checked into RE24 resolves this issue? > > Thanks, > Quanah > > --=20 > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > --rw1j2W5jTxST7ATlUt2I8c5Ena44RM7Vs-- --ijumfDLdJ6N1xL1tHwFiTBhCBA9VnmThW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQ0v96iCbHqLp/cLlN6JVViNrqjowUCWRNJVwAKCRB6JVViNrqj o3iuAJ40OLMe/nQHhjOAO7Uhuaxj8OWnxgCeJqR819BAH7lwMmVsOqyhRGCdJXA= =oyIK -----END PGP SIGNATURE----- --ijumfDLdJ6N1xL1tHwFiTBhCBA9VnmThW--

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by quanah＠symas.com 10 May '17

10 May '17

Hi Stephen, Would you be able to check and confirm if the fix for ITS#8648 that has been checked into RE24 resolves this issue? Thanks, 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#8648) sasl_client_init called concurrently causes issues
by ryan＠nardis.ca 09 May '17

09 May '17

An Ubuntu user confirmed that this change solved their issue with slapd and multiple syncrepl clients using GSSAPI. https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/comments/6

1 0

Re: (ITS#8650) EAGAIN from gnutls_handshake not respected
by ryan＠nardis.ca 07 May '17

07 May '17

Committed the fix, and pinged the submitter to test it.

1 0

(ITS#8650) EAGAIN from gnutls_handshake not respected
by ryan＠openldap.org 07 May '17

07 May '17

Full_Name: Ryan Tandy Version: RE24 OS: Debian URL: Submission from: (NULL) (24.68.41.160) Submitted by: ryan https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861838 That bug's submitter seems to have unintentionally configured their slapd with the entire list of system CAs. They're fixing it, but we have a bug here too. When the ServerHello is larger than 16kb, gnutls_handshake can return GNUTLS_E_AGAIN. In theory this was always possible, but I'm only seeing it happen with gnutls 3.x and haven't the exact change responsible. We need to loop gnutls_handshake until it completes, like we do already in the re-handshake case.

1 0

Re: (ITS#8648) sasl_client_init called concurrently causes issues
by hyc＠symas.com 02 May '17

02 May '17

ryan(a)nardis.ca wrote: > On Fri, Apr 28, 2017 at 02:52:44PM +0000, ryan(a)nardis.ca wrote: >> 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. > > SASL version was a red herring. I accidentally linked with Debian's > libldap (2.4.31) when I tested that. Mea culpa. > > The culprit does indeed seem to be the ITS#6798 change, as Quanah > suggested. Reverting b483ee1a ("Drop ldap_int_sasl_mutex") on RE24 and > linking with libldap_r makes my test program work. > > Since the proof-of-concept patch I posted above also makes my test > program work, I'm back to thinking that calling sasl_client_init > concurrently is the real bug here. > >> 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'm still not happy with the idea of calling sasl_client_init from > ldap_int_initialize, as it does a bunch of work (loading plugins and > such) that non-SASL users don't care about. However, I haven't as yet > thought of another fix that works for libldap as well as libldap_r. > > Would love to hear others' thoughts on this. Maybe fixing for libldap_r > only (and documenting that) is a good enough compromise? Yes, if the problem only exists in concurrent use then it's only relevant to libldap_r. -- -- 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

Re: (ITS#8581) slapd-meta backend SSL negociation timeout
by louis.chanouha＠test.univ-toulouse.fr 02 May '17

02 May '17

I looked deeper into the source, and i found the problem. Non-blocking socket seems to be implemented in starttls connection only, not in direct-SSL (ldaps://) which use a blocking socket. The problem isn't openssl or gnutls related. Another solution could be to set the socket timeout to a more reasonable value. I would like to help more, but this kind of modification is too complicated for my actual knowledge of sockets. Regards.

1 0

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

02 May '17

On Fri, Apr 28, 2017 at 02:52:44PM +0000, ryan(a)nardis.ca wrote: >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. SASL version was a red herring. I accidentally linked with Debian's libldap (2.4.31) when I tested that. Mea culpa. The culprit does indeed seem to be the ITS#6798 change, as Quanah suggested. Reverting b483ee1a ("Drop ldap_int_sasl_mutex") on RE24 and linking with libldap_r makes my test program work. Since the proof-of-concept patch I posted above also makes my test program work, I'm back to thinking that calling sasl_client_init concurrently is the real bug here. >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'm still not happy with the idea of calling sasl_client_init from ldap_int_initialize, as it does a bunch of work (loading plugins and such) that non-SASL users don't care about. However, I haven't as yet thought of another fix that works for libldap as well as libldap_r. Would love to hear others' thoughts on this. Maybe fixing for libldap_r only (and documenting that) is a good enough compromise?

1 0

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

29 Apr '17

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/

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