Delegate Privileged Mode authentication to sudo/PAM without corrupting the TUI #3

New issue

Closed

opened 2025-08-19 07:11:48 +00:00 by phg · 1 comment

phg commented

2025-08-19 07:11:48 +00:00

Owner

Problem

When entering Privileged Mode without cached sudo authorization, hosts collects a password in its own modal and passes it to sudo -S -v. This assumes password-only authentication, prevents configured PAM methods such as Touch ID from owning the interaction, and can corrupt the Textual interface if interactive sudo is run without first releasing the terminal.

Required behavior

hosts never collects, stores, or pipes authentication credentials.
First try sudo -n -v so cached authorization enters Privileged Mode without disturbing the TUI.
If interaction is required, temporarily suspend Textual, run one foreground sudo -v invocation with inherited terminal input and output, then restore and redraw the TUI.
The configured sudo/PAM stack owns prompts, authentication methods, retries, and explanatory output.
Do not impose an application timeout on interactive authentication.
Successful authorization must still be followed by write-permission validation and creation of the Pre-edit Backup before Privileged Mode begins.
Rejection, cancellation, interruption, unsupported terminal suspension, or operational failure must leave the application in Read-only Mode.
After an unsuccessful PAM conversation, show: “Authorization was not granted; remaining in Read-only Mode.”
Show specific actionable messages for operational failures such as unavailable sudo, unsupported suspension, failed permission validation, or failed backup creation.
Remove the password modal and its dedicated styling.
Do not change credential invalidation when leaving Privileged Mode; that remains tracked by #4.
Update the README password-specific description.

Acceptance evidence

Automated tests mock all sudo and terminal boundaries; they never invoke real sudo or PAM.
Tests cover cached authorization, successful and failed interactive authorization, cancellation/interruption, unsupported suspension, permission-validation failure, and backup failure.
Manual verification covers:
- cached sudo authorization;
- an interactive configured PAM method such as macOS Touch ID;
- password fallback where available;
- clean TUI restoration after success and failure.

Documentation impact

The existing glossary terms Privileged Mode, Read-only Mode, and Pre-edit Backup cover this behavior. No new glossary entry or ADR is needed.

## Problem When entering Privileged Mode without cached sudo authorization, `hosts` collects a password in its own modal and passes it to `sudo -S -v`. This assumes password-only authentication, prevents configured PAM methods such as Touch ID from owning the interaction, and can corrupt the Textual interface if interactive sudo is run without first releasing the terminal. ## Required behavior - `hosts` never collects, stores, or pipes authentication credentials. - First try `sudo -n -v` so cached authorization enters Privileged Mode without disturbing the TUI. - If interaction is required, temporarily suspend Textual, run one foreground `sudo -v` invocation with inherited terminal input and output, then restore and redraw the TUI. - The configured sudo/PAM stack owns prompts, authentication methods, retries, and explanatory output. - Do not impose an application timeout on interactive authentication. - Successful authorization must still be followed by write-permission validation and creation of the Pre-edit Backup before Privileged Mode begins. - Rejection, cancellation, interruption, unsupported terminal suspension, or operational failure must leave the application in Read-only Mode. - After an unsuccessful PAM conversation, show: “Authorization was not granted; remaining in Read-only Mode.” - Show specific actionable messages for operational failures such as unavailable `sudo`, unsupported suspension, failed permission validation, or failed backup creation. - Remove the password modal and its dedicated styling. - Do not change credential invalidation when leaving Privileged Mode; that remains tracked by #4. - Update the README password-specific description. ## Acceptance evidence - Automated tests mock all sudo and terminal boundaries; they never invoke real sudo or PAM. - Tests cover cached authorization, successful and failed interactive authorization, cancellation/interruption, unsupported suspension, permission-validation failure, and backup failure. - Manual verification covers: - cached sudo authorization; - an interactive configured PAM method such as macOS Touch ID; - password fallback where available; - clean TUI restoration after success and failure. ## Documentation impact The existing glossary terms **Privileged Mode**, **Read-only Mode**, and **Pre-edit Backup** cover this behavior. No new glossary entry or ADR is needed.

phg added the

Kind/Bug

label 2025-08-19 07:11:48 +00:00

phg referenced this issue

2026-09-03 07:35:17 +00:00

Stop invalidating the global sudo timestamp on privileged-mode exit #4

phg added the

Priority

High

label 2026-09-03 07:38:33 +00:00

phg changed title from ~~sudo elevation does not check for alternative PAM methods~~ to Delegate Privileged Mode authentication to sudo/PAM without corrupting the TUI

2026-09-03 16:27:29 +00:00

phg commented

2026-09-03 17:24:20 +00:00

Author

Owner

Implemented in commit 026bbc4 (Delegate privileged authentication to sudo PAM). Cached sudo, foreground PAM authentication, TUI restoration, failure handling, tests, and documentation are complete.

Implemented in commit 026bbc4 (Delegate privileged authentication to sudo PAM). Cached sudo, foreground PAM authentication, TUI restoration, failure handling, tests, and documentation are complete.

phg closed this issue

2026-09-03 17:24:20 +00:00