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

[ryan@nardis.ca]

On Fri, Apr 28, 2017 at 02:52:44PM +0000, ryan@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@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?