[15729] in Kerberos_V5_Development
Re: krb5_get_in_tkt_with_password -> gss_init_sec_context()
daemon@ATHENA.MIT.EDU (vir vir)
Thu Apr 29 14:25:25 2010
Message-ID: <234302.76095.qm@web50104.mail.re2.yahoo.com>
Date: Thu, 29 Apr 2010 11:25:20 -0700 (PDT)
From: vir vir <vitrou2004@yahoo.com>
To: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="iso-8859-1"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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@MIT.EDU> wrote:
From: Greg Hudson <ghudson@MIT.EDU>
Subject: Re: krb5_get_in_tkt_with_password -> gss_init_sec_context()
To: "vir vir" <vitrou2004@yahoo.com>
Cc: "krbdev@mit.edu" <krbdev@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.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
