krb5_get_in_tkt_with_password -> gss_init_sec_context()
vitrou2004 at yahoo.com
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 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.
More information about the krbdev