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. > > > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
