Skip to content

fix(trust): make trust install runnable — drop the wrong sudo, wire stdin, use abs path - #102

Merged
gustavobertoi merged 1 commit into
mainfrom
fix/trust-sudo-remediation
Jul 1, 2026
Merged

fix(trust): make trust install runnable — drop the wrong sudo, wire stdin, use abs path#102
gustavobertoi merged 1 commit into
mainfrom
fix/trust-sudo-remediation

Conversation

@gustavobertoi

Copy link
Copy Markdown
Contributor

Problem (reported live)

devstack doctor recommends sudo devstack trust install, and running it fails with sudo: devstack: command not found. Three bugs:

  1. sudo devstack → "command not found". sudo resets PATH to secure_path, which excludes ~/.local/bin. (The binary is installed at ~/.local/bin/devstack, with ds → symlink — just invisible to sudo.)
  2. Running the whole CLI under sudo is wrong for mkcert: CAROOT resolves to root's home, so the CA is created in /root/.local/share/mkcert while cert generation (as the user) looks in ~/.local/share/mkcert. mkcert self-elevates for only the system-store step, so trust install must run as the user.
  3. Even as the user it would fail: execRunner.Run wired stdout/stderr but not stdin, so mkcert's internal sudo had no terminal to prompt for a password.

Fix

  • trust install remediation now says devstack trust install (as your user, not sudo).
  • execRunner.Run wires os.Stdin so mkcert's sudo prompt works.
  • Genuinely-root remediations (dns setup, uninstall) use the absolute binary path via a new sudoSelfCmd helper (os.Executable()), so sudo <abs>/devstack … works despite secure_path.

Tests

  • CA-not-installed remediation no longer contains sudo devstack … and points at trust install.
  • sudoSelfCmd renders an absolute path.

Build (CGO=0), go vet, trust/cli tests all green.

🤖 Generated with Claude Code

… stdin, use abs path

`devstack doctor` told users to `sudo devstack trust install`, which failed on
three counts:

1. `sudo devstack` → "command not found": sudo resets PATH to its secure_path,
   which excludes ~/.local/bin, so a user-local install isn't found.
2. Running the whole CLI as root is wrong for mkcert anyway — it puts the CA in
   root's CAROOT (/root/.local/share/mkcert), so cert generation (run as the
   user) can't find it. mkcert self-elevates its own sudo for just the system
   store, so `trust install` must run as the user.
3. Even run as the user, `execRunner.Run` wired stdout/stderr but not stdin, so
   mkcert's internal sudo had no terminal to prompt for a password and failed.

Fixes: trust-install remediation now says `devstack trust install` (as the user,
no sudo); execRunner.Run wires os.Stdin so mkcert's sudo can prompt; and the
remediations that genuinely need root (`dns setup`, `uninstall`) now use the
absolute binary path via a new sudoSelfCmd helper (os.Executable()), so
`sudo <abs>/devstack …` works despite secure_path.

Tests: the CA-not-installed remediation no longer says `sudo devstack …` and
points at `trust install`; sudoSelfCmd renders an absolute path.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@gustavobertoi
gustavobertoi merged commit 15fe475 into main Jul 1, 2026
4 checks passed
@gustavobertoi
gustavobertoi deleted the fix/trust-sudo-remediation branch July 1, 2026 13:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant