#1110220 sudo: setting the clock forward by a mere 67s invalidates the timestamp_timeout

Package:
sudo
Source:
sudo
Description:
Provide limited super user privileges to specific users
Submitter:
Thorsten Glaser
Date:
2026-01-29 10:23:02 UTC
Severity:
normal
Tags:
#1110220#5
Date:
2025-08-01 12:01:18 UTC
From:
To:
On bootup of my work laptop, I have to log in on the console, then start the network
(basicallty a “sudo ifup wlan0=some-id” or “sudo ifup eth0”, depending), then step the
clocktime with rdate, then run another command with sudo.

Unfortunately, the stepping of the time-of-day often invalidates the timestamp, and
I have to enter the password again, which is annoying. (It seems to have a tolerance
for values below 60s or so, the laptop generally loses about a minute between boots.)

I get why stepping backwards will require the password again (though I set a higher
than normal timestamp_timeout), but forwards should not, at least not by small amounts
(less than six hours or so)
#1110220#10
Date:
2025-08-01 15:58:05 UTC
From:
To:
Control: tags -1 upstrean
Control: severity -1 minor

That sounds like a workflow that noone else uses. Setting severity
appopriately.

I find that reasonable. Maybe for security reasons. I'd like to know how
sudo detects that between invocations.

Six hours is well beyond the password timeout.

Debian is surely not going to patch this part of sudo's behavior.

May I ask you to take this upstream yourself, maybe to the upstream
mailing list? This is much more efficient than me forwarding messages.

Greetings
Marc
#1110220#19
Date:
2025-08-06 15:29:16 UTC
From:
To:
Marc Haber dixit:

Perhaps. It’s annoying, though, for such small jumps.

Probably with utmp/wtmp/… or something like that.

Fair.

Meanwhile… turns out installing util-linux-extra brings back hwclock,
and then the laptop’s clocktime, after a full power cycle, is only
about two seconds off, which reduces that problem (for if others have
the same problem).

bye,
//mirabilos