krb5 cc iteration and selection functions

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

krb5 cc iteration and selection functions

Love-5

Hello,

I extended the krb5_cc api for Heimdal recently to support iteration and
cache selection. Jeffery Altman asked me to post about them here.

I've written about why they are useful here:
http://blogs.su.se/lha/Heimdal/20051021182400.1129911904771.html

Some question that jeff rasied, and I punted on when I did the
implementation because it was simpler, is that the NULL type is suppsed to
do. Really it should probably iterate over all caches.

Love


/*
 * Start iterating over all caches of `type'. If `type' is NULL, the
 * default type is * used. `cursor' is initialized to the beginning.
 * Return 0 or an error code.
 */

krb5_error_code KRB5_LIB_FUNCTION
krb5_cc_cache_get_first (krb5_context context,
                         const char *type,
                         krb5_cc_cache_cursor *cursor)

krb5_error_code KRB5_LIB_FUNCTION
krb5_cc_cache_next (krb5_context context,
                   krb5_cc_cache_cursor cursor,
                   krb5_ccache *id)

/*
 * Destroy the cursor `cursor'.
 */

krb5_error_code KRB5_LIB_FUNCTION
krb5_cc_cache_end_seq_get (krb5_context context,
                           krb5_cc_cache_cursor cursor)


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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: krb5 cc iteration and selection functions

Alexandra Ellwood

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. Jeffery Altman asked me to post about them here.
>
> I've written about why they are useful here:
> http://blogs.su.se/lha/Heimdal/20051021182400.1129911904771.html
>
> Some question that jeff rasied, and I punted on when I did the
> implementation because it was simpler, is that the NULL type is  
> suppsed to
> do. Really it should probably iterate over all caches.
>
> Love
>
>
> /*
>  * Start iterating over all caches of `type'. If `type' is NULL, the
>  * default type is * used. `cursor' is initialized to the beginning.
>  * Return 0 or an error code.
>  */
>
> krb5_error_code KRB5_LIB_FUNCTION
> krb5_cc_cache_get_first (krb5_context context,
>              const char *type,
>              krb5_cc_cache_cursor *cursor)
>
> krb5_error_code KRB5_LIB_FUNCTION
> krb5_cc_cache_next (krb5_context context,
>            krb5_cc_cache_cursor cursor,
>            krb5_ccache *id)
>
> /*
>  * Destroy the cursor `cursor'.
>  */
>
> krb5_error_code KRB5_LIB_FUNCTION
> krb5_cc_cache_end_seq_get (krb5_context context,
>                krb5_cc_cache_cursor cursor)
>

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


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

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.

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.

(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.)  :-)


--lxs

Alexandra Ellwood <[hidden email]>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: krb5 cc iteration and selection functions

hartmans
Do you really want to return an array or just a cursor that only
selects caches with that principal?


--Sam

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: krb5 cc iteration and selection functions

Jeffrey Hutzelman


On Saturday, October 29, 2005 06:41:53 PM -0400 Sam Hartman
<[hidden email]> wrote:

> Do you really want to return an array or just a cursor that only
> selects caches with that principal?

Returning a cursor sounds like a reasonable idea, and it even seems
like it would not be all that hard to do, as a sort of filter over the
basic iteration operation.

I was thinking of suggesting passing the match operation a predicate to be
called on each potential match, to decide whether it should be returned.
But I think I like the cursor-based approach better, as it's somewhat more
general.

-- Jeff
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: krb5 cc iteration and selection functions

Love Hörnquist Åstrand
In reply to this post by Alexandra Ellwood

Alexandra Ellwood <[hidden email]> 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


attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>



_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: krb5 cc iteration and selection functions

Love Hörnquist Åstrand

Alexandra Ellwood <[hidden email]> writes:

>> 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.
So if I just drop the _cc from the name, it would be fine ? Right now its
implemented using krb5_cc function and really don't need to know anything
about the existing krb5_cc internals now that I've add those other krb5_cc
cache iteration functions.

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

I'm not sure if I agree with this in the sense that I think the
functionallity should exists, and having more processes running doesn't
make the system less complex and hard to manage.

Love


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

attachment0 (487 bytes) Download Attachment