krb5_get_in_tkt_with_password -> gss_init_sec_context()

vir vir vitrou2004 at
Thu Apr 29 14:25:20 EDT 2010

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>
Cc: "krbdev at" <krbdev at>
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.

More information about the krbdev mailing list