krb5_gss_acquire_cred() vs multiple credential caches

[Alexandra Ellwood]

If you call gss_acquire_cred() with a desired_name then the gss  
library searches the cache collection for a ccache containing valid  
tickets for the desired_name.  If it finds any, the  ccache is passed  
back wrapped in the output_cred_handle argument.  Further uses of  
output_cred_handle should use that ccache, not a ccache determined by  
krb5int_cc_default() or the krb5_context.

If there is no desired_name specified, then output_cred_handle  
instead contains the ccache returned by krb5int_cc_default().  If the  
user is prompted by krb5int_cc_default(), it should still return the  
ccache the user created when they got new tickets and continue using  
that ccache when output_cred_handle is specified.  So long as code  
consistently uses output_cred_handle, the same ccache should be used  
throughout.

The relevant code that does this is in acquire_init_cred() in  
acquire_cred.c.


Note: the above statements assume that the caller did not call  
gss_krb5_ccache_name().  If that function is called, gss_acquire_cred 
() will ignore the desired_name and always use the ccache the caller  
specified with gss_krb5_ccache_name().  However even in this case  
neither krb5int_cc_default() nor the krb5_context are used to select  
credentials.


It sounds like either output_cred_handle is not being created  
correctly or is not being passed around properly.


On Feb 12, 2007, at 12:27 AM, 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.
>
> 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
>
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

--lxs

Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>