[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: preauth_always option?
On May 29, 2008, at 17:44, Michael B Allen wrote:
>> I would think you'd want to bury this code in the library, and maybe
>> have a flag at the API layer enabling or disabling the use of the
>> cached data, but otherwise leave it for the internal implementation,
>> which has access to all that info. Why do you think it should be
>> at a
>> higher level?
> Because the library doesn't know how the application would like to
> ETYPE_INFO data.
> Some applications might want to put it in a file (e.g. kinit). In my
> scenario simply saving the one ETYPE_INFO as a hint in a static
> of the function calling krb5_get_init_creds_whatever would be
> to eliminate 99% of the faulty AS-REQs.
Ah, I see. I figured it would be the library, and thus independent of
whatever application was doing the caching, and applicable even if you
use a different application to get credentials the next time (e.g.,
pam at login time, then kinit after expiration). But I guess there
are cases where you don't have, for example, a home directory
available, and you may need to do something else...
The etype-info data cache will probably solve a lot of cases, but if
you need to use preauth, you still wind up having to configure that,
or incur the round-trip to have the KDC tell you. Saving the preauth
type too -- or maybe exporting a opaque "AS-REQ info cache" blob from
the library, which might be extended later -- might be better. Maybe
the opaque blob only contains etype-info to start, but is set up to be