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.
- 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.