Skip to content

Support doas and pre-elevated execution in udev rules installer#254

Open
hypery11 wants to merge 1 commit into
flipperdevices:devfrom
hypery11:feature/privsep-support
Open

Support doas and pre-elevated execution in udev rules installer#254
hypery11 wants to merge 1 commit into
flipperdevices:devfrom
hypery11:feature/privsep-support

Conversation

@hypery11

Copy link
Copy Markdown

Closes #242.

The udev-rules installer in both setup_rules.sh (source tree) and the AppImage entry-point script (installer-assets/appimage/AppRun) currently hard-codes sudo. On systems where sudo is not installed — Alpine, Void, Artix, anything minimal, or simply containers — the install/uninstall path crashes with sudo: command not found, even when the user is already root.

The fix introduces a small detect_privsep helper that picks the right approach at runtime:

Situation What gets used
Already running as root (id -u == 0) No wrapper at all — commands run directly
sudo available sudo (existing behaviour)
doas available (Alpine / Void / Artix / OpenBSD-style) doas
None of the above Bails out early with a clear error pointing at the three valid options

The user-facing prompt is also made dynamic — it now says e.g. "You may be asked for your doas password." instead of always "SUDO password".

Verification

Tested in three Docker scenarios with TERM=xterm to bypass the unrelated clear issue:

  1. Root + no sudo/doas (debian:bookworm): runs through the "danger zone", fails on udevadm (no udev daemon in container, as expected), reports "Something went wrong" — but importantly, detect_privsep no longer aborts before that point.
  2. Unprivileged + no sudo/doas (debian:bookworm): fails fast at detect_privsep with the clear "Re-run this script as root, or install one of the above" message. Matches the Expected behavior in the issue.
  3. Unprivileged + doas installed (alpine:latest): picks doas, prints "You may be asked for your doas password.", invokes doas udevadm .... The sudo-only path was not separately tested but is byte-for-byte equivalent.

(The sudo-only branch can't easily be exercised in a container because the bookworm apt mirror was failing to install sudo cleanly at test time, but the codepath is identical in shape to the doas one and would only differ if sudo and doas behaved differently as command prefixes, which they don't for this use.)

Files touched

  • setup_rules.sh (+30 / -12)
  • installer-assets/appimage/AppRun (+33 / -10)

Both files keep their original control flow; the change is only at the points that previously called sudo directly.

Notes for review

  • detect_privsep is duplicated across the two files rather than factored out, because they're standalone scripts shipped in different contexts (source tree vs. AppImage bundle) and pulling them through a shared file would create a packaging dependency that doesn't currently exist. Happy to fold them together if you'd rather.
  • bool is explicitly excluded from the int short-circuit in Python land — not relevant here, but mentioning because the same pattern matters in similar code; in shell $(id -u) -eq 0 already handles only int returns so no analogous guard is needed.
  • I left the unrelated clear / set -e interaction at the top of setup_rules.sh alone (it fails noisily when there's no TTY), since that's a different bug.

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.

setup_rules.sh: fails if sudo is not available.

1 participant