From d99d4fc6de0bc99d48c9935724fa19d7fb41ae54 Mon Sep 17 00:00:00 2001 From: Omarchybot Date: Mon, 24 Aug 2026 15:49:17 +0200 Subject: [PATCH] Remove the sudo lockout reset command (#8046) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Nothing in the repository called omarchy-sudo-reset, and its one line interpolated an environment-supplied $USER into a string handed to a root shell: `su -c "faillock --reset --user $USER"`. $USER is an environment variable rather than a kernel-supplied identity, so whatever set it before the command ran chose the rest of what root's shell executed. That is not a way past PAM on its own — su still has to authenticate — but the installer sets root's password to the user's own, so the prompt this raises is one the user answers by habit. It bought little for that. Omarchy sets `deny=10 unlock_time=120` in /etc/pam.d/system-auth and in the lock screen's PAM stack, so a lockout takes ten wrong passwords to reach and clears itself two minutes later, and the manual documents the root-TTY reset for anyone who would rather not wait. Co-authored-by: David Heinemeier Hansson Co-authored-by: Claude Opus 5 (1M context) Co-authored-by: Codex XHigh --- bin/omarchy-sudo-reset | 5 ----- 1 file changed, 5 deletions(-) delete mode 100755 bin/omarchy-sudo-reset diff --git a/bin/omarchy-sudo-reset b/bin/omarchy-sudo-reset deleted file mode 100755 index 56d91a8d..00000000 --- a/bin/omarchy-sudo-reset +++ /dev/null @@ -1,5 +0,0 @@ -#!/bin/bash - -# omarchy:summary=Reset the sudo lockout/faillock for the current user. - -su -c "faillock --reset --user $USER"