[Date Prev][Date Next]
Re: (ITS#6280) Race condition in TLS/SSL init code
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6280) Race condition in TLS/SSL init code
- From: firstname.lastname@example.org
- Date: Thu, 3 Sep 2009 01:33:35 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> Full_Name: Jeff Lewis
> Version: 2.4.17
> OS: SuSE Linux, ES9& 10
> Submission from: (NULL) (220.127.116.11)
> 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/