FreeBSD-SA-22:14.heimdal (breaks my site)

After upgrading I get this
kinit: krb5_get_init_creds: Clock skew too great
and this
kdc[6798]: Too large time skew, client time 1970-01-01T01:00:00 is out by 1668625860 > 300 seconds

Which translates to: no tickets, no database, no ssh, no automation.
 
From wikipedia,
Kerberos has strict time requirements, which means that the clocks of the involved hosts must be synchronized within configured limits.
 
OP
PMc

PMc

Yes, that's the case. The limit is 300 seconds.

But I don't think any of my clocks shows 1970-01-01T01:00:00 and DOES NOT MOVE.
 
OP
PMc

PMc

Hi cy,

time is within <10ms on concerned systems.

I can isolate the problem to the KDC system. Behaviour from patched and unpatched clients is identical, and when reverting the SA-22:14 on the KDC system, things do work again.

I tried to isolate a specific patch from the SA-22:14 patchset, but was unsuccessful so far: subsets of the patches did not trigger the problematic behaviour.
 

cy@

Developer
Can you open a PR for this? I'd like to bring philip@ into this discussion. He got the patch from the heimdal folks over a week ago and tested the patch on the FreeBSD cluster for a week before it was committed. I tested it here too but my KDC is MIT. (The MIT KDC suffered a similar problem, though it was an integer overflow.)

Looking at the patch I doubt the KDC PAC portion of the patch would have had anything to do with this. That code was moved to execute earlier in the path.

I'll refrain from asking more questions here. Just open a PR and assign to me.
 
OP
PMc

PMc

Yeah, I'm working on it. I'll open a PR when I have robust data. I have split that patchset into halves, and each of them worked without error. So something is strange here. That might have to do with my treatment of META_MODE and git timestamps, or whatever, anyway I want to find out first.
 
kdc[6798]: Too large time skew, client time 1970-01-01T01:00:00 is out by 1668625860 > 300 seconds
That is The Beginning of Time in the UTC+1 time zone. Well as far as POSIX is concerned, anyway.

Looks like some integer representing time is getting set to 0 somewhere.
 

cy@

Developer
It's resolved. The patch caused ASN1 to replace the timestamp with zeros when UTC was set in the request. Thanks to the sleuthing of PMc@ by the time I woke this morning.

Poking around with a heimdal-devel port for those who want to track upstream development. The final build looks like it might be a quick win.
 
Top