krb5_gss_acquire_cred() vs multiple credential caches
jaltman at secure-endpoints.com
Mon Feb 12 12:07:06 EST 2007
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
> The relevant code that does this is in acquire_init_cred() in
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.
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20070212/786cd6cb/attachment.bin
More information about the krbdev