krb5 cc iteration and selection functions

[Alexandra Ellwood]

On Nov 1, 2005, at 8:55 AM, Love Hörnquist Åstrand wrote:

>>> /*
>>>  * Search for a matching credential cache of type `type' that  
>>> have the
>>>  * `principal' as the default principal. If NULL is used for `type',
>>>  * the default type is used. On success, `id' needs to be freed with
>>>  * krb5_cc_close or krb5_cc_destroy. On failure, error code is
>>>  * returned and `id' is set to NULL.
>>>  */
>>>
>>> krb5_error_code KRB5_LIB_FUNCTION
>>> krb5_cc_cache_match (krb5_context context,
>>>              krb5_principal client,
>>>              const char *type,
>>>              krb5_ccache *id)
>>
>
>> This function appears to do almost (but not quite) the same thing  
>> as one
>> of the mostly commonly used code paths in the Kerberos Login Library
>> (KLL).
>>
>> The big difference is that the KLL usually needs to find the first  
>> cache
>> containing *valid* initial tickets for a given client principal.  By
>> valid I mean non-expired, ip-address-matching, non-needs-validation
>> tickets.  If no valid tickets exist then the KLL tries
>> renewing/validating the first invalid ones it finds.  If the KLL  
>> can't
>> renew and the application is a GUI app, it tries to prompt the  
>> user for
>> more tickets.
>
> So adding the restriction that the credential cache return must be  
> valid
> and adding a krb5_promp function pointer (and assosited pointer)  
> will solve
> your concern ? If the promper function is NULL, the call failes if  
> it can't
> find a matching credentail.
>

No I don't think the function should prompt.  That would be outside  
the scope
of behavior of the krb5_cc_* functions.  I'm not even sure if it  
should check
for validity since the other krb5_cc_* functions don't know anything  
about the
meaning of the fields in the creds structure.

Back when we were coming up with the CCAPI we always had to fight the  
desire
to make the CCAPI smarter (ie: having the CCacheServer auto-renew, etc).
Invariably we decided against these features because they add  
complexity and
break the abstraction barrier between the data storage layer and the  
libraries
that use it.  In the long run I think our attitude has helped keep  
the CCAPI
manageable both from code maintenance and security standpoints.


>> Since there may be multiple ccaches with the same client principal in
>> them (especially if you change the NULL type to mean search over all
>> types), the KLL can't use this function.  What it really needs is  
>> either
>> for this function to return an array of krb5_ccaches that match the
>> client principal or to also check validity.  The latter seems like  
>> a bad
>> idea because none of the other krb5_cc_* functions deal with  
>> validity.
>
> I think its of that this function is doing more, the the other krb5_cc
> functions. Maybe a flag field should be passed in to control the  
> behavior.
>
>> Obviously the existence of this function doesn't stop me from
>> implementing my KLL algorithm using the iterators above.  However  
>> since
>> the KLL's algorithm will share a lot of code in common with this  
>> one, I
>> wonder if we need both.  I'd recommend keeping this function  
>> internal (I
>> assume you're using it to implement your gss_acquire_cred support)  
>> and
>> then implementing the new KLL one when we finalize the new API.   
>> If this
>> function has already shipped exported with Heimdal, I will  
>> probably still
>> argue in favor of MIT Kerberos not exporting it unless someone can  
>> come
>> up with a case where it's useful and the KLL behavior wouldn't be  
>> more
>> useful.
>
> I'm think I fine with unexporting the function in heimdal, there  
> are no
> release containing the function.
>
>> (Note that the new KLL API will be cross-platform and implemented for
>> KfM, KfW and the Unix ports of MIT Kerberos.  I will be posting a
>> proposed API for it in the next couple weeks and would be very  
>> happy if
>> Heimdal folks participated in the API review process and  
>> implemented it.)
>> :-)
>
> I guess I'll wait and see what the new KLL does and what problem its
> supposed to solve.

Working on it.  :-)


--lxs

Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>