krb5_gss_acquire_cred() vs multiple credential caches

[Jeffrey Altman]

There is a problem with krb5_gss_acquire_cred() when the user obtains
initial tickets in a credential cache that is not the default credential
cache for the session.

krb5_gss_acquire_cred() allocates a new krb5_context for each call. 
acquire_init_cred() uses this new context to call krb5int_cc_default().
krb5int_cc_default() in turn calls
not_an_API_Leash_AcquireInitialTicketsIfNeeded() which returns the name
of the credential cache containing the credentials to be used by the caller.
krb5int_cc_default() then calls krb5_cc_set_default_name() and returns
the ccache to acquire_init_cred().

When krb5_gss_acquire_cred() exits it destroys the krb5_context and with
it the knowledge of the ccache to be used for the process is lost. 

For each mech, gss_acquire_cred() will generate a call to
krb5_gss_acquire_cred() and because of the lack of preservation of the
new default ccache name, the end user will be prompted repeatedly. 

Any thoughts on how this should be addressed?  Perhaps a thread local
storage allocation for maintaining the default ccache outside of the
krb5_context.

Thanks.

Jeffrey Altman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20070212/185e5b0f/attachment.bin