From 625b7e38a304710bde7add3b6896eb88fc64cac9 Mon Sep 17 00:00:00 2001 From: Bernardo Magri Date: Tue, 14 Jul 2026 12:48:16 +0100 Subject: [PATCH] docs(hardware): sudo path of parallel fingerprint passes; drop a check that cannot fail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bernardo, AMD dev box, gen 422, fingerprint.pam = true (parallel default): one prompt, typed password works, sensor works, wrong-finger x3 falls back to password. Three of the item's counts confirmed on the real reader. The fourth — "password keeps working with fprintd stopped" — is removed as a trap rather than checked off. fprintd is D-Bus activated, so `systemctl stop` does not keep it down: PAM asks D-Bus, D-Bus restarts it. Bernardo ran it and reported that *the fingerprint still worked*, which is precisely the evidence that the daemon came back and the dead-reader path was never exercised. A check that passes whether or not the property holds is worse than no check. The property itself needs no hardware: password is `auth sufficient` at order 11700, independent of the fprintd rule at 11400, so no fprintd failure can gate it — visible by eval on the rendered pam.d text, and asserted in the VM with no reader by checks.hardware-toggles. Doing it for real would need `systemctl mask`, and masking a working machine's auth daemon to re-prove an evaluated invariant is not a trade worth making. Still open on this item: hyprlock, the greeter (needs the reboot), and `fingerprint.parallel = false` restoring sequential behavior. Co-Authored-By: Claude Opus 4.8 --- agent/HARDWARE-QUEUE.md | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/agent/HARDWARE-QUEUE.md b/agent/HARDWARE-QUEUE.md index ee9d21c..d920347 100644 --- a/agent/HARDWARE-QUEUE.md +++ b/agent/HARDWARE-QUEUE.md @@ -158,18 +158,27 @@ the **T14s** (webcam case). `systemd-inhibit --list`, `hyprctl monitors all -j`, `hyprctl workspaces -j`, and `pactl --format=json list sinks` before changing state again. - [ ] **Parallel fingerprint-or-password on the real reader** (AMD dev - box, 2026-07-12) — with a finger enrolled and - `fingerprint.pam = true` (parallel is the default): `sudo -k true` - must show ONE prompt ("Enter Password or Place finger…"); typing - the password immediately works, touching the sensor instead works, - wrong-finger ×3 falls back to password, and password keeps working - with fprintd stopped (`systemctl stop fprintd`). Also check - hyprlock and the greeter accept both factors and don't wedge on a - leftover prompt after a fingerprint win (known cosmetic quirk of - the hack — pthread_cancel'd prompt). `fingerprint.parallel = false` - must restore the old sequential behavior. VM already asserts the - PAM stack shape + password-only lockout safety with no reader - (checks.hardware-toggles). + box, 2026-07-12) — **sudo path PASSED 2026-07-14** (Bernardo, dev box, + gen 422, `fingerprint.pam = true`, parallel default): `sudo -k true` + showed ONE prompt, the typed password worked, touching the sensor + instead worked, and wrong-finger ×3 fell back to password. + **Still open:** hyprlock and the greeter must accept both factors and + not wedge on a leftover prompt after a fingerprint win (known cosmetic + quirk of the hack — pthread_cancel'd prompt); `fingerprint.parallel = + false` must restore the old sequential behavior. + **Do NOT "check password still works with `systemctl stop fprintd`"** — + that check was in this item and it is a trap that cannot fail. fprintd + is D-Bus activated, so PAM asks D-Bus and D-Bus starts it straight back + up: Bernardo ran it and *the fingerprint still authenticated*, which is + the tell that the daemon never stayed down. It proves nothing about a + dead reader. The property it was reaching for is structural anyway — + password is `auth sufficient` at order 11700, independent of the fprintd + rule at 11400, so no fprintd failure can gate it (verify by eval: + `nix eval --raw #nixosConfigurations..config.security.pam + .services.sudo.text`), and checks.hardware-toggles asserts that shape in + the VM with no reader at all. If someone genuinely wants it on hardware + it needs `systemctl mask` + stop, and masking a working machine's + authentication daemon to re-prove an evaluated invariant is a bad trade. - [ ] **#55 fingerprint enroll on real reader** — with `nomarchy.hardware.fingerprint.enable` and a physical reader: System › Fingerprint › Enroll a finger; List shows it; Verify succeeds; optional