Re: Clarification regarding global ldapoptions structure in ldap

[Howard Chu <hyc@symas.com>]

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


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