Slightly confused by user-to-user authentication...

Chris Hecker checker at d6.com
Fri Jul 8 02:38:48 EDT 2011


greg:
> ccache is read. There's no code in the memory ccache type to do
> anything with clock skew.

I assume I could patch the memory cache to store them like the file 
cache does?

ken:
> information available. Sigh. I'm not completely sure that the side
> that processes AP_REQs handles that correctly (has that ever been
> tested?), but it will be interesting to find out.

I will definitely be testing this thoroughly, because I'm assuming my 
customers will have clocks set to rand().

Chris


On 2011/07/07 17:39, Greg Hudson wrote:
> On Thu, 2011-07-07 at 19:16 -0400, Chris Hecker wrote:
>> Do you know if the memory cc will do the right thing with clock skew
>> during the duration of the program?  I'm still trying to decide what
>> kind of cc to use.
>
> The answer is complicated.
>
> In the current code, the clock skew is determined for a krb5_context
> when the context is used to get initial credentials, or when a file
> ccache is read.  There's no code in the memory ccache type to do
> anything with clock skew.
>
> So, some scenarios:
>
> 1. Create a krb5_context, call krb5_get_init_creds_password() to get
> initial credentials, store them in a memory ccache, perform other
> Kerberos operations using the memory ccache: here the clock skew is used
> for all operations because the context has its clock skew set when
> initial creds are obtained.
>
> 2. Create a krb5 context, get initial credentials, store them in a file
> ccache.  In the same process or another process, create another krb5
> process and perform Kerberos operations using the file ccache: here the
> clock skew it used because it is stored in the file ccache and set in
> the new context when the file ccache is read.
>
> 3. Create a krb5 context, get initial credentials, store them in a
> memory ccache.  Then perform GSSAPI krb5 operations using the memory
> ccache.  Here the clock skew is not used, because the GSSAPI operations
> are performed in a different krb5 context and the memory ccache doesn't
> save or restore the clock skew.
>
> The third scenario is arguably a bug, but it's the way the code
> currently is.
>
>
>



More information about the Kerberos mailing list