rig/changelog.d/139.md

5 lines
391 B
Markdown
Raw Normal View History

fix: refuse a PATH without /usr/sbin, before the token prompt Reported from a real ci-box: `rig forgejo-runner install` read a registration token off the operator's terminal and then died with …/forgejo-runner-install.sh: line 250: useradd: command not found rig checked `id -u` and concluded it could administer the machine. Being root and being able to FIND the admin binaries are different facts, and only the first was asserted. `su` without `-`, sudo with a sanitised secure_path, and several container images all produce a root shell with no /usr/sbin on PATH, which is where useradd lives. Three call sites had it: both runner installers and users apply. The last is the worst — it runs mid-convergence, so a PATH-shorn root could fail partway through a user sweep rather than before it starts. require_admin_bins refuses rather than repairing PATH itself: a command that quietly prepends /usr/sbin teaches the operator nothing and leaves a misconfigured host misconfigured. The message names the remedy and, deliberately, not this script — echoing an internal path back at someone who typed `rig forgejo-runner install` is the unhelpful half of the original error. It sits beside each root check, so identity and capability are asserted together and before anything is spent. A secret typed for a run that could never succeed is the avoidable half of this bug, and there is a test for exactly that ordering. Closes #139 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-01 18:39:03 +00:00
### Fixed
fix: preflight every admin binary a command uses, not only useradd Addresses codex (1538) and kimi (1539): the sweep caught the reported incident and not the class. Both are right, and there were four sites, not three. forgejo-runner-install useradd -> useradd usermod (usermod -aG docker, reached only after the token has been spent) users-apply useradd usermod -> + groupadd (called two lines into convergence), and visudo when a role needs it bootstrap-tenant NEW site (kimi) — usermod -aG docker runs AFTER docker and node are installed, so an unguarded PATH fails it mid-convergence on a changed machine runner-install unchanged: useradd is the only admin binary it calls, and declaring more would refuse boxes that are fine visudo is checked after the sudo-install block rather than beside the root check, because until sudo is installed its absence has an innocent cause. Below that block it does not: sudo is present, so a missing visudo means /usr/sbin is off PATH. That case is the quiet one — the sudoers block reads `command -v visudo` as "no sudo on the box means no role needed it", so apply reported success having granted roles without the escalation those roles exist for. The other three sites at least crash. Measured which binaries this covers (Debian 13): useradd, usermod, groupadd, userdel, groupdel and visudo are /usr/sbin; gpasswd is /usr/bin and so is NOT affected and deliberately not preflighted. visudo shares the directory but ships in `sudo`, not `passwd` — which is why it needs its own treatment. Tests: the sbin-less fixtures could only ever prove the FIRST binary is named, since useradd wins every race. Six new checks use partial PATHs that resolve the earlier binaries and withhold exactly one, plus the ordering assertions (no token prompt, no group created) and the negative case — a users file needing no sudo must NOT be refused for a missing visudo. Refs #139
2026-08-02 00:05:02 +00:00
- `rig forgejo-runner install`, `rig runner install`, `rig users apply` and `rig bootstrap <tenant>` refuse with a named remedy when root's `PATH` carries no `/usr/sbin`, instead of dying on `useradd: command not found` after prompting for a token (#139)
- `rig users apply` no longer reports success having silently skipped the sudoers drop-in when `visudo` is off `PATH` (#139)