Credential cache searching, ccapi and file caches
hartmans at MIT.EDU
Wed Jul 14 16:58:29 EDT 2004
>>>>> "Alexandra" == Alexandra Ellwood <lxs at MIT.EDU> writes:
Alexandra> While I was looking at replying to Sam's mail I ended
Alexandra> up looking at the library code and noticed something
Alexandra> about the way people use krb5_cc_get_principal():
Alexandra> When you init a krb5 or GSS context, the library picks
Alexandra> up the value of KRB5CCNAME (or the CCAPI system default
Alexandra> cache) to determine which tickets to use. It then uses
Alexandra> krb5_cc_get_principal() to figure out what the client
Alexandra> principal is and requests a service ticket with that
Alexandra> client principal by calling krb5_get_credentials().
Alexandra> This krb5_cc_get_principal/krb5_get_credentials
Alexandra> mechanism of getting service tickets is used by kadmin,
Alexandra> kpasswd, gss_init_sec_context(), krb5_mk_req(),
Alexandra> krb5_sendauth() and a substantial number of third-party
Alexandra> apps (eg: sidecar, ssh, samba, etc). I suspect we will
Alexandra> have to continue to support it.
Yes. I'd really hoped to put off this discussion for a bit, but as I
think about the problem more I'm not sure that's a good idea. It may
be that our solution to the krb5_cc_get_principal problem will
influence which approach for library integration is correct.
Alexandra> I assume that what we intended to do was to put the TGT
Alexandra> searching code in krb5_get_credentials() and use the
Alexandra> client principal the caller got from
Alexandra> krb5_cc_get_principal() as a hint (ie: try this one
Alexandra> first) rather than a template. As a result, the
Alexandra> returned service principal would not necessarily have
Alexandra> the same client principal as the one passed into
Alexandra> krb5_get_credentials(). For most of the code I found
Alexandra> on the web, this seems like it would work fine.
I'd actually assumed you'd modify krb5get_credentials to accept a null
client principal, modify gss_init_sec_context and all the applications
in our tree.
This would mean that some applications would not support credential
searching explicitly, but everything that continued to work would
still work. It would also mean that in the new world order, correct
applications would have to call less functions (no
krb5_cc_get_principal), which I consider a change for the better.
Finally, if an application did want a particular client principal it
would use the relatively intuitive interface of requesting that
Your approach works as well. It has the advantage of causing all
applications to support the new behavior immediately. It has the
disadvantage of providing confusing behavior to the applications. For
example, this might create significant problems for applications like
SASL libraries that use the default principal as part of an
authorization name. You could get into situations where part of a
protocol uses one name based on the applications expectation from
krb5_cc_get_principal and another part of the protocol uses the name
from the ticket. If we preserve the current behavior then things will
either work or fail cleanly.
More information about the krbdev