Re: Clarification regarding global ldapoptions structure in ldap

sachidananda sahu wrote:

Hi All,

Any one can give a thought on this ?

Your problem description makes no sense. Unless you're explicitly calling ldap_set_option in multiple threads, the option structure is read-only.

The default libldap is not threadsafe, nor is it meant to be. You should probably be using libldap_r.

On Thu, Aug 1, 2019 at 7:55 PM sachidananda sahu <sachi059@gmail.com mailto:sachi059@gmail.com> wrote:

Hi All,

I recently upgraded to openldap 2.4.47, it's working with single threaded connection but with multi threaded getting problem due to global structure of
ldapoptions in init.c

-------------------------
init.c
-------------------------

*struct* ldapoptions <http://opengrok-prd.eng.netapp.com/source/s?defs=ldapoptions&project=dev> ldap_int_global_options <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_int_global_options&project=dev> =
        { LDAP_UNINITIALIZED <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_UNINITIALIZED&project=dev>, LDAP_DEBUG_NONE <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_DEBUG_NONE&project=dev>
                LDAP_LDO_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_NULLARG&project=dev>
                LDAP_LDO_CONNECTIONLESS_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_CONNECTIONLESS_NULLARG&project=dev>
                LDAP_LDO_TLS_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_TLS_NULLARG&project=dev>
                LDAP_LDO_SASL_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_SASL_NULLARG&project=dev>
                LDAP_LDO_GSSAPI_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_GSSAPI_NULLARG&project=dev>
                LDAP_LDO_MUTEX_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_MUTEX_NULLARG&project=dev> };


This global structure is accessed at multiple places (such as ldap_pvt_tls_init_def_ctx <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_pvt_tls_init_def_ctx&project=dev>, alloc_handle <http://opengrok-prd.eng.netapp.com/source/s?refs=alloc_handle&project=dev>, ldap_int_tls_connect <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_int_tls_connect&project=dev>, *ldap_pvt_tls_destroy <http://opengrok-prd.eng.netapp.com/source/xref/R9.6x/third_party/open_source/openldap/distro/libraries/libldap/tls.c#152>, ldap_ld_free*)

in tls2.c using the macro lo <http://opengrok-prd.eng.netapp.com/source/s?defs=lo&project=dev>= LDAP_INT_GLOBAL_OPT
<http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_INT_GLOBAL_OPT&project=dev>(); 

So in case of multi threaded application multiple ldap connection will be using this global structure, for example ldo_tls_ctx of lapoptions will be used.
In one thread it can be creating a tls connection and in one it can be destroying the connection. As it's global so it is getting corrupted. 

Is openldap library thread safe completely ? Because this variable seems to be not for this tls context variable, is there any other way of using this
context . As i can see a local variable ldo_tls_ctx exist in dap ld->ldc->ldap_options->ldo_tls_ctx structure, but it's just got assigned with the same
address of global structure in  ldap_int_tls_connect <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_int_tls_connect&project=dev>.

So can someone share some thoughts on it ?

-- 
Regards,
Sachidananda Sahu

-- Regards, Sachidananda Sahu +91-9035265767