Passwordless sudo expiry is lost on reboot, leaving NOPASSWD active

[lbonvarl]

+## Summary

The passwordless-sudo expiry mechanism can leave unrestricted passwordless sudo active after a reboot.

omarchy-sudo-passwordless creates:

/etc/sudoers.d/99-omarchy-nopasswd-$USER

with:

$USER ALL=(ALL) NOPASSWD: ALL

It schedules removal with a transient systemd timer:

sudo systemd-run --on-active=15m --timer-property=AccuracySec=1s \
  --unit=omarchy-nopasswd-expire-$USER \
  rm /etc/sudoers.d/99-omarchy-nopasswd-$USER

If the system reboots before the timer fires, systemd stops and discards the transient timer, but the sudoers file survives on disk. After reboot, unrestricted passwordless sudo remains active indefinitely.

Reproduction

1. Enable Passwordless Sudo for the default 15-minute period.
2. Reboot or shut down before the 15 minutes expire.
3. Log in again.
4. Observe that the generated sudoers file still exists and sudo -n true succeeds, while omarchy-nopasswd-expire-$USER.timer no longer exists.

Observed on

• Omarchy 4.0.1
• Arch Linux/systemd
• The timer works during an uninterrupted session: previous runs removed the file after 15 minutes.
• In the failure case, the reboot happened immediately before the deadline; systemd logged the transient timer being deactivated during shutdown, with no cleanup of the sudoers file.

The helper has a stale-file cleanup check when it is invoked again, but there is no boot-time cleanup or persistent expiry state.

Security impact

A user may believe the 15-minute passwordless-sudo window has ended after reboot, while any process running as that user can still execute arbitrary commands as root without authentication.

Design decision

Which policy should Omarchy adopt?

1. Fail closed on reboot: remove generated passwordless-sudo drop-ins during boot, so reboot always ends the passwordless window.
2. Honor the original deadline across reboot: persist an expiry deadline and ensure cleanup survives reboot, including shutdown, crash, and power-loss cases.
3. Defense in depth: use a persistent deadline plus boot-time cleanup of stale generated drop-ins.

The first option is simpler and safer, but the intended “15 minutes” semantics may suggest the second. Either way, the current combination of a persistent sudoers file and a non-persistent timer should be closed.

Suggested acceptance criteria

• Reboot before expiry never leaves an untracked generated NOPASSWD: ALL rule.
• Normal uninterrupted expiry continues to remove the rule.
• Crash/power-loss behavior is documented or handled explicitly.
• Cleanup is limited to Omarchy-generated drop-ins and does not touch user-managed sudoers files.

[rookepoole]

Two additional open PRs implement fixes for this same reboot-surviving passwordless-sudo grant:

• [Security] Key passwordless sudo grants off id -un, not USER #9082 adds boot-time cleanup, verified timer creation, fail-closed publication, and a bounded grant window.
• [codex] Complete passwordless sudo expiry across suspend #9457 adds the broader OM-SEC-01 remediation: absolute wall-clock expiry, root-owned state and locking, verified timers, boot cleanup, package-removal revocation, legacy migration, and extensive race/corruption coverage.

Linking both alongside the already-associated #9387 so maintainers can consolidate the competing security fixes.