krb5_gss_acquire_cred() vs multiple credential caches
jaltman at secure-endpoints.com
Mon Feb 12 08:03:21 EST 2007
Ken Raeburn wrote:
> 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...)
Every time the krb5int_cc_default() is called, if there are no
credentials in the default ccache, the user will be prompted to obtain
The failure here is that krb5int_cc_default() is being called when it
shouldn't be called. The first time krb5int_cc_default() was called
credentials were obtained and the credential cache they were stored in
was set as the default ccache using krb5_cc_set_default(). This sets
the default ccache in the krb5_context. This would work except for the
fact that the krb5_context is destroyed.
The next time krb5_gss_acquire_cred() is called it allocates a new
krb5_context, and then because there is no principal name specified it
calls krb5int_cc_default_cred() which once again looks at the global
session default instead of the credential cache containing the
credentials the user requested.
>> Any thoughts on how this should be addressed? Perhaps a thread local
>> storage allocation for maintaining the default ccache outside of the
> 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.
Where globally you mean for the process?
-------------- 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/50bce2d3/attachment.bin
More information about the krbdev