Creating GSSAPI initiate credential using keytab entry

[Richard Evans]

Greg

All is working fine now - I can use the credentials from gss_aqcuire_creds in gss_init_sec_context
To set up a SASL connection to an LDAP server.

However I found that if I destroyed the cache and freed the context before the gss_init_sec_context call, I
got a segfault:

[libkrb5.so.3+0x3e279]  krb5_copy_principal+0x39
[libkrb5.so.3+0x325c6]
[libkrb5.so.3+0x34e21]  krb5_cc_get_principal+0x21
[libgssapi_krb5.so.2+0x222db]
[libgssapi_krb5.so.2+0x223ee]
[libgssapi_krb5.so.2+0x16775]
[libgssapi_krb5.so.2+0xab08]  gss_init_sec_context+0x178

Is that what I would expect?  Should I have not freed the krb5_principal object?  I did that immediately after
the krb5_cc_initialize call.

The code I used to free the context and cache was:

krb5_cc_destroy(ctxt, cache);
krb5_free_context(ctxt);    

This is on x86 Fedora 12 with the krb5-devel-1.7.1-2.fc12.i686 package.

Richard

-----Original Message-----
From: Greg Hudson [mailto:ghudson at MIT.EDU] 
Sent: 09 March 2010 04:49
To: Richard Evans
Cc: krbdev at mit.edu
Subject: Re: Creating GSSAPI initiate credential using keytab entry

On Mon, 2010-03-08 at 20:11 -0500, Richard Evans wrote:
> I assume the context needs to be freed after the gss_acquire_creds
> call? ie the context is storing the memory cache?

Memory caches are stored in a global (but mutex-protected) list, so
they're independent of the context they were created in.  You can clean
up the krb5 context as soon as you are ready to stop referencing it.

However, you'll need to reference the context to destroy the memory
ccache, which you shouldn't do until after the gss_acquire_creds call.

> One of the platforms I was experimenting was is AIX 5.3.  The Kerberos
> library there does not contain krb5_cc_new_unique.  Is there by any
> chance an older way of doing the same thing? The headers there mention
> krb5_cc_gen_new but it does not appear to be in the library.

You can pick a memory cache name yourself ("MEMORY:whatever") and
resolve it with krb5_cc_resolve().  You'll need to ensure the uniqueness
of the name if multiple instances of this operation might be taking
place at the same time.