krb5_gss_acquire_cred() vs multiple credential caches

Jeffrey Altman 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
new credentials.

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
>> 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.
Where globally you mean for the process?  

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/50bce2d3/attachment.bin


More information about the krbdev mailing list