Re: (ITS#6280) Race condition in TLS/SSL init code

[hyc@symas.com]

donald.lewis@teradata.com wrote:
> Full_Name: Jeff Lewis
> Version: 2.4.17
> OS: SuSE Linux, ES9&  10
> URL:
> Submission from: (NULL) (153.65.16.10)
>
>
> There appears to be a race condition in SSL/TLS setup in the LDAP client library
> bind fucntions.  We have workarounds for the problem in 2.3 and 2.4 which we
> plan to use until we can get a proper fix so there is no time pressure on you
> from my end.  Since we have a viable workaround, we're happy leaving the choice
> to address the issue or not to you.

libldap is not documented to be thread-safe, nor is it intended to be.

> 2. If, before the first bind attempt, I invoke ldap_set_option passing a NULL
> LDAP pointer, LDAP_OPT_X_TLS_NEWCTX and a value of 0, I do not experience the
> problem.  We're quite happy with this as a workaround.  This supports my belief
> that the race is somewhere in the TLS initialization code.
>
> In 2.3.39 (our current OpenLDAP client), the problem is more severe.  When
> multiple threads collide in the TLS setup logic, the problem causes TLS to
> become completely unusable and no connection can be established to the server.
> We've repaired this problem in libraries/libldap/tls.c by calling
> ldap_pvt_tls_init through pthread_once and we're quite happy to live with this
> until we can get a 2.4 OpenLDAP imported.

Your app is responsible for making sure that all libldap init functions are 
processed before multiple threads are created. Using pthread_once or whatever 
approach you take is up to you.

Closing this ITS.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/