On 10/07/2015 11:00 AM, Adamson, Andy wrote: > —— from the ticket: —— > > This unnecessarily strict check causes a particularly bad experience > when (a) the client's clock is slightly ahead of the server's clock, > and (b) the maximum service ticket lifetime is lower than the maximum > TGT lifetime. > > —— —— > I think both a) and b) are incorrect. > > for a) you got it backwards. this occurs when the server clock is ahead of the client clock. Yes, I did write the wrong thing there; I will follow up on that. > for b) the relationship between the TGT lifetime and the service ticket lifetime is irrelevant. Only the service ticket lifetime has any effect as the client will use a valid service ticket to construct an RPCSEC_GSS_INIT request irregardless of the TGT lifetime value. I will try one more time to communicate what I mean: * If the service ticket end time is less than the TGT end time, then gss_init_sec_context() fails during the clock skew window, and starts succeeding again afterwards. * If the service ticket and TGT have both expired (according to the server), then gss_init_sec_context() fails, and keeps failing afterwards, unless there is some out-of-band agent refreshing expired TGTs. Put another way: we expect authentications to start failing around the time the TGT expires. We do not expect authentications to start failing around the time a service ticket expires, if the TGT is still valid. That is what I refer to as a "particularly" bad experience. If that isn't clear, perhaps we should ignore this as a moot point; it doesn't really affect how we plan to change the krb5 code. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
