krb5_gss_acquire_cred() vs multiple credential caches

[Ken Raeburn]

On Feb 12, 2007, at 00:27, Jeffrey Altman wrote:

> 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.

Prompted for what?  If the user is being prompted for the password  
repeatedly, that sounds like two problems.  First, why is the user  
prompted for each mech instead of just the Kerberos-based mech, and  
second, why aren't the credentials still there from the first time  
the user was asked for the password?  (Unless you mean the user  
cancels the password entry...)

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

If the name generation mechanism isn't going to come up with the same  
name each time barring outside influence (like setting an environment  
variable), then yes, absolutely it needs to be maintained outside the  
context -- though perhaps globally and not per-thread.

Ken