A cached sudo timestamp is a policy decision with a lifetime
Sudo authentication is often treated as a one-time event followed by a short period of convenience. The timestamp cache is more accurately a policy object. It decides whether a later invocation can inherit proof of an earlier authentication, which terminal or process it belongs to, and how long that proof survives.
The sudoers manual documents timestamp_type, timestamp_timeout, and the way time stamps are associated with the user, terminal, and process session. The default behavior and available types can vary by build and configuration. A review should inspect the effective configuration on the host rather than relying on a generic Linux default.
A global timestamp can be reused across sessions in ways that a tty or ppid policy would prevent. A long timeout increases the window after a user walks away. A negative timeout can be configured to avoid expiration, which may be intentional on a dedicated console but is a poor fit for a shared endpoint. The system clock and monotonic-clock behavior also affect how records are evaluated.
Session scope is not command authorization
The timestamp cache does not encode an approval for every future command. It records that authentication happened recently enough for sudo's policy to accept. The sudoers rule still decides which command and arguments the user may run. Treating the cache as a business approval can turn a permitted administrative command into an unintended privileged operation.
The cache also interacts with terminal multiplexing, remote sessions, and process parents. A record associated with a tty may outlive the user's visible session. A record associated with a parent process may be reused by a child process. Those are normal implementation details, not proof that a cached authentication is stale in every case. They are reasons to test the intended session boundary.
Inspect and verify
On each host class, run sudo -V to identify the build and supported timestamp options. Read the effective sudoers policy with visudo or a validated configuration dump, then record timestamp_type, timestamp_timeout, and any per-user overrides. Check whether the timestamp directory is cleared at boot and whether the host can access a reliable boot-time record.
Test with a non-administrative account in a lab. Authenticate once, open a second terminal, and verify which invocation asks for a password again. Let the timeout expire and repeat. Test a command that remains denied even after authentication. Do not use an operator's real privileges or a production emergency account as the test subject.
The result should match the operational expectation. If an administrative session can inherit authentication from a different terminal or a stale parent process, document why that scope is acceptable. If the answer is simply that the default is convenient, the timestamp policy needs an owner and a shorter period.
Top comments (0)