Credential cache searching, ccapi and file caches

[Sam Hartman]

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

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.

--Sam