Credential cache searching, ccapi and file caches
hartmans at MIT.EDU
Thu Jul 15 14:02:40 EDT 2004
>>>>> "Alexandra" == Alexandra Ellwood <lxs at MIT.EDU> writes:
Alexandra> On Jul 14, 2004, at 4:58 PM, Sam Hartman wrote:
>>>>>>> "Alexandra" == Alexandra Ellwood <lxs at MIT.EDU> writes:
Alexandra> I am concerned that unless the krb5_get_credentials()
Alexandra> is explicit about what it does that the krb5 callers
Alexandra> will still try to use krb5_cc_get_principal() to get
Alexandra> the client principal name. In many of the applications
Alexandra> the calls to krb5_cc_get_principal() aren't anywhere
Alexandra> near the calls to krb5_get_credentials(). I bet people
Alexandra> would be tempted to just change the client principal to
Alexandra> a NULL and expect to pick up the new behavior.
I'd assume this is what people would do and I'd assume it would just work.
Alexandra> I'd prefer a new function name whose name implies the
Alexandra> new behavior. This would also have the advantage that
Alexandra> folks could test for the presence of the function in
Alexandra> configure and change what their code does depending on
Alexandra> whether the feature is there. Otherwise they have to
Alexandra> do a complicated test of the behavior of
Alexandra> krb5_get_credentials() (ick).
I don't horribly object to a new function.
Alexandra> If we have a new function then I don't see why we need
Alexandra> to change what a krb5_ccache is at all, because the new
Alexandra> function can just take a new cache collection type or
Alexandra> inherit the cache collection from the krb5_context
Alexandra> depending on whether or not we want to support having
Alexandra> multiple cache collections (CCAPI doesn't support
Alexandra> this). Then we wouldn't need to retrofit the new
Alexandra> behavior into an existing type which already has an
Alexandra> established meaning in developers' minds.
So here we get back to the disagreement about what is the cleaner
approach. My position as of two days ago is that I actually thought
that the krb5 library did not need an object representing a smaller
collection of ticckets than all the tickets you want to use at a given
time. In addition, I believe that treating krb5_ccache as that
interface is a backward-compatible evolution of that interface's
current functionality. As of two days ago, I did not see a good
reason to prefer either your view of the problem or my view of the
I thought about your questions, possible answers we may get from users
and the implications of these answers last night. I want to wait a
day or two before discussing these thoughts on the list because I
think getting answers to your questions from the user community is
very important and I'd rather consider all the feedback before
continuing the design discussion. ALso, I'm busy with the preauth
draft until the end of the week.
More information about the krbdev