krb5_gss_acquire_cred() vs multiple credential caches

[Jeffrey Altman]

Alexandra Ellwood wrote:
>
> 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.
Yes.  There is LOGIN_LIBRARY code and LEASH code that both do the same
things but with different function names.
>
> 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.
>
Correct.
>
> It sounds like either output_cred_handle is not being created
> correctly or is not being passed around properly.
The problem was occurring within gss_acquire_cred() before the
output_cred_handle was returned to the caller.

krb5_gss_acquire_cred() is called multiple times within
gss_acquire_cred() and each time krb5_gss_acquire_cred() was allocating
a new krb5_context and the logic that would have obtained the previously
returned ccache name was failing.

I think we are all in agreement with how this code should behave.

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/786cd6cb/attachment.bin