Credential cache searching, ccapi and file caches

[Alexandra Ellwood]

On Jul 15, 2004, at 2:02 PM, Sam Hartman wrote:

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

Unfortunately these apps assume that service ticket they get from 
krb5_get_credentials() has the same client principal as the client 
principal returned by krb5_cc_get_principal().  If they only change the 
krb5_cc_get_principal() call just before krb5_get_credentials(), that 
won't fix any code which calls krb5_cc_get_principal() and uses the 
result elsewhere in the app.  telnet, ssh, and kermit have this 
problem: they all call krb5_cc_get_principal() in multiple places.

What I am really concerned about is the general problem of developer 
reeducation.  The third party apps I looked at which call 
krb5_cc_get_principal() all assume that there is only one client 
principal in a krb5_ccache and that the krb5_ccache's default client 
principal is set to that principal.  There are also a number of places 
in the krb5 library and KLL which make this assumption.  That means 
that there are a substantial number of Kerberos developers out there 
who have an existing idea of what these structures mean.  Hence my 
concerns below about changing what a krb5_ccache is rather than 
creating some new interface.

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

That's fine.


--lxs
-----------------------------------------------------------------------
Alexandra Ellwood                                           lxs at mit.edu
MIT Information Services & Technology           http://mit.edu/lxs/www/
-----------------------------------------------------------------------