krb5_get_in_tkt_with_password -> gss_init_sec_context()

[vir vir]

Yes, I agree definitely
the problem is my library runs under multi thread environment and another thread can use gss_krb5_cache_name() and change the path or run gss_acquire_cred(). 
 
But if you say  gss_krb5_ccache_name() uses TLS or thread-specific  for each thread keep it's own variable then I can use it in multitread ignoring the problem of somebody changing the cache path in another thread .


--- On Thu, 4/29/10, Greg Hudson <ghudson at MIT.EDU> wrote:


From: Greg Hudson <ghudson at MIT.EDU>
Subject: Re: krb5_get_in_tkt_with_password -> gss_init_sec_context()
To: "vir vir" <vitrou2004 at yahoo.com>
Cc: "krbdev at mit.edu" <krbdev at mit.edu>
Received: Thursday, April 29, 2010, 10:53 AM


On Wed, 2010-04-28 at 19:01 -0400, vir vir wrote:
> you mean TLS to thread-specific variable ?

Windows calls it TLS (thread-local storage).  Pthreads calls it
thread-specific data.  They're the same thing.

I don't believe it's enough to just have gss_krb5_ccache_name() set
during the gss_acquire_cred() call; you also need it set to the desired
ccache during the gss_init_sec_context() calls.