Credential cache searching, ccapi and file caches

Ken Hornstein kenh at
Thu Jul 15 13:26:36 EDT 2004

>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.

I could be wrong ... but my reading of the Cyrus-SASL library is that it
passes in GSS_C_NO_NAME as the "client principal equivalant" and doesn't
get the client name out until after authentication is complete.  So
maybe this isn't a problem for Cyrus-SASL (but like you said, it could
be a problem for other applications).

A while ago I wrote some heavily-commented sample applications with
a bunch of comments in them to help explain the krb5 API to people we
were doing work with.  I know it's not a substitute for "real"
API documentation, but if it would help at all, they're available.
Sure, it's probably too late to solve this problem, but it might solve
future problems like this if developers at least get some kind of hint
on what they're supposed to be doing.


More information about the krbdev mailing list