[15566] in Kerberos_V5_Development
Re: Creating GSSAPI initiate credential using keytab entry
daemon@ATHENA.MIT.EDU (Russ Allbery)
Mon Mar 8 12:21:04 2010
From: Russ Allbery <rra@stanford.edu>
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <1268068287.18898.334.camel@ray> (Greg Hudson's message of "Mon,
08 Mar 2010 12:11:27 -0500")
Date: Mon, 08 Mar 2010 09:20:59 -0800
Message-ID: <873a0ak9vo.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Greg Hudson <ghudson@MIT.EDU> writes:
> * Create a ccache with krb5_cc_new_unique(). Pass "MEMORY" as the type
> parameter and NULL as the hint. Clean this up later with
> krb5_cc_destroy().
This assumes that you are linking your program with the same Kerberos
library that's used by the underlying GSSAPI Kerberos mechanism
implementation and hence destroys GSSAPI implementation agility. But yes,
this is probably a reasonable tradeoff in most situations. (It's not a
tradeoff that I can make in the example code that I posted; it's a
requirement of that code that it be able to use an underlying GSSAPI
mechanism implementation linked with a different Kerberos library than
its.)
> * Use gss_krb5_ccache_name() to get GSSAPI to use your memory ccache.
> (Call krb5_cc_get_name() to get the ccache name.) This function sets a
> thread-specific variable.
I didn't realize this was thread-specific. Thanks for that! I was
assuming that was going to do something equivalent to setting the
environment variable, since it doesn't take a GSSAPI context or any other
state information.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
