Re: krb5 cc iteration and selection functions

[Love Hörnquist Åstrand <lha@kth.se>]

Alexandra Ellwood <lxs@MIT.EDU> writes:

> On Oct 28, 2005, at 9:20 AM, Love wrote:
>
>>
>> Hello,
>>
>> I extended the krb5_cc api for Heimdal recently to support
>> iteration and cache selection.
[...]
>
> These functions look fine to me.  We needed to do this anyway.  :-)
>
> I do agree with Jeff that if there are multiple ccache types available
> that NULL should iterate over all of them.  This is especially important
> for KfW (which has the LSA and API types), and for Linux (which will have
> keyring and API types in the future).

Ok, I can live with that.


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

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

Thanks for your comments.

Love

PGP signature