Hi Howard,
Some clarification with respect to this statement "The context is per-process state, not per-thread state. No threads should be trying to destroy the context."
Consider in my process i have two threads, each want to connect to their respective LDAP server. As two LDAP server so two different certificate and two different tls context. In that case that process specific global variable will be overwritten, considering concurrent case (One thread is in ldap_int_tls_start as part of allocation and further use and other thread in ldap_unbind_ext--->ldap_ld_free-->ldap_int_tls_destroy(&ld->ld_options );).
So the concern is two treads connecting to two LDAP server independently (starting ldo_tls_ctx from same global variable or ldap_unbind_ext where they free the ldo_tls_ctx) . The same global variable getting used through two different LDAP server connection, two different ld context. So clarity needed with this concurrent scenario,
1. Here we are storing the local context ldo_tls_ctx with after extracting from global option structure ldo_tls_ctx.
ldap_int_tls_connect( LDAP *ld, LDAPConn *conn, const char *host ) { ... Sockbuf *sb = conn->lconn_sb; int err; tls_session *ssl = NULL;
if ( HAS_TLS( sb )) { ber_sockbuf_ctrl( sb, LBER_SB_OPT_GET_SSL, (void *)&ssl ); } else { struct ldapoptions *lo; tls_ctx *ctx;
* ctx = ld->ld_options.ldo_tls_ctx;* ------------------------- ssl = alloc_handle( ctx, 0 );
if ( ssl == NULL ) return -1;
#ifdef LDAP_DEBUG ber_sockbuf_add_io( sb, &ber_sockbuf_io_debug, LBER_SBIOD_LEVEL_TRANSPORT, (void *)"tls_" ); #endif ber_sockbuf_add_io( sb, tls_imp->ti_sbio, LBER_SBIOD_LEVEL_TRANSPORT, (void *)ssl );
lo = LDAP_INT_GLOBAL_OPT(); if( ctx == NULL ) { *ctx = lo->ldo_tls_ctx; -------------------- Storing the global context in to ld specific local context. * ld->ld_options.ldo_tls_ctx = ctx; tls_ctx_ref( ctx ); } ... }
2. ldap_ld_free is deleting that ld specific context but inside that the context is same as global option structure ldo_tls_ctx.
int ldap_ld_free( LDAP *ld, int close, LDAPControl **sctrls, LDAPControl **cctrls ) { ... #ifdef HAVE_TLS * ldap_int_tls_destroy( &ld->ld_options ); ----------------- Destroying the tls_ctx inside this function, though it is extracting from ld, but it carries the address of global option ldo_tls_ctx as per point 1.* #endif ..... }
void *ldap_int_tls_destroy*( struct ldapoptions *lo ) { if ( lo->ldo_tls_ctx ) {
* ldap_pvt_tls_ctx_free( lo->ldo_tls_ctx ); lo->ldo_tls_ctx = NULL;* } ... }
On Wed, Aug 7, 2019 at 12:05 AM Howard Chu hyc@symas.com wrote:
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 meshare my thoughts based on code.
> > ldap_set_option called from many threads, not only that evenldap_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 structureis read only.
> > Let's consider ldapoptions->ldo_tls_ctx which is global and can beused 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 itmessed 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 noexisting 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 fromglobal option context.
> > *ldap_pvt_tls_destroy( void )* > { This is an OpenLDAP-specific private API. If you're calling thisfunction, 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'reexplicitly 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 workingwith 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 ldapconnection 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 inone it can be destroying the connection. As it's global so it is getting corrupted.
> > > > Is openldap library thread safe completely ? Becausethis 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_ctxexist 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/