fix(cli): make non-root read-only commands work on Linux (EPERM liveness, sbin PATH)#11
Conversation
|
Warning Review limit reached
More reviews will be available in 18 minutes and 49 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (7)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Two follow-up fixes to the Linux sudo work from #9 — both the kind of thing that only shows up the first time you actually drive it as a non-root user on a real Linux box, which is exactly where they surfaced.
The headline one: after an auto-elevated
fleetbox up, a plainfleetbox lsorfleetbox sshreported the running VM as stopped. The holder liveness probe usedkill(pid, 0) == nil, but a non-root user probing the root-owned holder getsEPERM(the process exists, you're just not allowed to signal it across the uid boundary) — which the code read as "dead", so it never even reached the socket and fell through to "stopped". That quietly defeated the whole point of #9, where non-root read-only commands were supposed to just work. NowEPERMcounts as alive; only a genuinely absent process (ESRCH) is "not running".The second: the CLI's auto-elevation forwards the invoking user's
PATH, and a stock Debian loginPATHhas no/sbin. Theenvwrapper overrides sudo'ssecure_path, so the elevated holder couldn't findiptablesand network setup died — it only worked on #9's test box because that shell happened to have sbin on itsPATH. The elevatedPATHnow always carries the sbin directories.Both were validated on real hardware — the EPERM one on a non-root Linux box (the VM flipped from "stopped" to "running" with the fix), the PATH one by dogfooding the Linux path inside a fleetbox-booted VM. ADR-0023 and the architecture notes are updated to record both.
Checklist
ARCHITECTURE.mdupdated in this PRdocs/adr/(next sequential number)!in the title) → the description spells out what callers must change