Re: Clarification regarding global ldapoptions structure in ldap

[Howard Chu <hyc@symas.com>]

sachidananda sahu wrote:
> many thanks for the information.
> Now have couple of queries.
> 
> Then which call i should use to create the local context and destroy the tls context.

None. The context is created automatically and used as needed.
The context is per-process state, not per-thread state. No threads should be trying to destroy the context.

The reference implementations are in clients/tools in the source tree.
> 
> Currently i was calling ldap_start_tls_s->ldap_int_tls_start->ldap_int_tls_connect : here it was doing ctx
> <http://opengrok-prd.eng.netapp.com/source/s?defs=ctx&project=dev>= ld <http://opengrok-prd.eng.netapp.com/source/s?defs=ld&project=dev>->ld_options
> <http://opengrok-prd.eng.netapp.com/source/s?defs=ld_options&project=dev>.ldo_tls_ctx
> <http://opengrok-prd.eng.netapp.com/source/s?defs=ldo_tls_ctx&project=dev>;, So as this connection is newly started and to add tls context over LDAP we call
> ldap_start_tls_s .....So when we should allocate the assign memory for this local context. 
> 
> Currently It;s going for alloc_handle and creating a default context using global and assigning it to local context. 
> 
> Similarly many places it access the global option->ldo_tls_ctx many places, which function we should use for the destory of the context, considering multiple
> threads are there and creating and destroying connection.
> 
> If any reference implementation link also there, you can share.
> 
> Many thanks Howard for your insights.
> 
> 
> 
> 
> On Tue, Aug 6, 2019 at 10:42 PM Howard Chu <hyc@symas.com <mailto:hyc@symas.com>> wrote:
> 
>     sachidananda sahu wrote:
>     > Hi Howard,
>     > Thanks for your response. I may be missing something, but let me share my thoughts based on code.
>     >
>     > ldap_set_option called from many threads, not only that even  ldap_int_tls_connect, ldap_pvt_tls_init_def_ctx as multiple thread can connect to LDAP server.
>     > Based on code lookup, i feel not every members of option structure is read only.
>     >
>     > Let's consider ldapoptions->ldo_tls_ctx which is global and can be used by many threads. Suppose there is two threads and thread A may be at point 1 and
>     thread
>     > B may be at point 2, based on scheduling chances of getting it messed is more, which problem i am facing now. Have a look and please share in case my
>     > assumptions are wrong or i am missing something.
> 
>     init_def_ctx only gets called from alloc_handle() if there was no existing ctx.
>     >
>     > tls2.c
>     > ---------------------------
>     >
>     > 1. Let's see where ldo_tls_ctx get allocated.
>     > ldap_pvt_tls_init_def_ctx( int is_server )
> 
>     > 2. Let's see where it's getting freed. ldo_tls_ctx the same from global option context.
>     >
>     > *ldap_pvt_tls_destroy( void )*
>     > {
>     This is an OpenLDAP-specific private API. If you're calling this function, you're misusing the API.
> 
>     > On Tue, Aug 6, 2019 at 9:44 PM Howard Chu <hyc@symas.com <mailto:hyc@symas.com> <mailto:hyc@symas.com <mailto:hyc@symas.com>>> wrote:
>     >
>     >     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> <mailto:sachi059@gmail.com
>     <mailto:sachi059@gmail.com>> <mailto:sachi059@gmail.com <mailto:sachi059@gmail.com> <mailto: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 ldap_int_global_options  =
>     >     >             { LDAP_UNINITIALIZED , LDAP_DEBUG_NONE,
>     >     >                     LDAP_LDO_NULLARG ,
>     >     >                     LDAP_LDO_CONNECTIONLESS_NULLARG,
>     >     >                     LDAP_LDO_TLS_NULLARG,
>     >     >                     LDAP_LDO_SASL_NULLARG ,
>     >     >                     LDAP_LDO_GSSAPI_NULLARG,
>     >     >                     LDAP_LDO_MUTEX_NULLARG  };,
>     >     >
>     >     >
>     >     >     This global structure is accessed at multiple places (such as ldap_pvt_tls_init_def_ctx , alloc_handle, ldap_int_tls_connect ,
>     *ldap_pvt_tls_destroy ,
>     >     ldap_ld_free*)
>     >     >
>     >     >     in tls2.c using the macro lo = LDAP_INT_GLOBAL_OPT
>     >     >     (); 
>     >     >
>     >     >     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.
>     >     >
>     >     >     So can someone share some thoughts on it ?


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