Validate module --auto-install on a physical rooted device (MagiskSU two-parse model + cleanup)

[Xiddoc]

Summary

PR #37 (#7) shipped beetroot module <name> <zip> --auto-install for adb-adopted rooted devices with the full CI-level contract pinned by mocked, argv-exact tests (push → su -c 'magisk --install-module …' → cleanup rm, sha256 fail-closed, per-module reporting, hostile-filename injection tests). What it could not include — the development environment has no Android device or Docker daemon — is a run against a real MagiskSU.

This issue tracks that one-time smoke validation on a physical rooted phone (or any real adb target with Magisk) before the feature is treated as release-grade.

Why this is worth a real-device pass

The security fix in PR #37 rests on a specific model of two device-side shell parses: adb shell flattens argv into one line (parse 1: device shell), then MagiskSU re-joins everything after -c and executes it via an inner sh -c (parse 2). The fix (synthesized beetroot-module-<i>.zip temp names + dual-level shlex.quote) was hand-traced and review-approved against that model, but the model itself is exactly the kind of thing that varies across su implementations/versions — and mocked tests structurally cannot catch a wrong model, only a wrong implementation of it.

Checklist

• Happy path: a real module zip installs via --auto-install; module visible in magisk --list after reboot.
• Spaced local filename (My Module.zip) installs (synthesized remote name sidesteps both parses).
• Hostile local filename (e.g. $(true).zip — benign payload) installs normally, nothing executed, name never reaches a device shell.
• sha256 mismatch refused before any push.
• One bad zip in a multi-module batch: failed row + remaining modules still install; exit 1.
• Cleanup: no beetroot-module-*.zip left in /data/local/tmp after success AND after an install failure.
• Fold any divergence found back into the mocked tests (adjust the model, then the strings the tests pin).

Refs

• AdbDevice: auto-install modules directly into /data/adb/modules_update/ #7, PR AdbDevice: --auto-install for Magisk modules via su -c with sha256 enforcement and per-module reporting (#7) #37 (the "physical-device smoke test … still worthwhile before release" note in its body, and the security re-review's hand trace).
• Related but distinct: [Feature] First-class LSPosed recipe: install LSPosed + an Xposed/LSPosed module APK and enable it in scope (real nativeLibraryDir) #29 (LSPosed recipe) — same hardware session could cover both.

[Xiddoc]

Progress (PR #43, merged): an in-CI automation path for this validation now exists.

Booting a real rooted Android on a hosted runner is now demonstrated — a redroid Android-14 booted green on ubuntu-latest and was driven via Beetroot's adb backend. That's the prerequisite for running this --auto-install checklist headless in CI instead of on a hand-plugged phone.

The new e2e.yml workflow's Tier 2 (a WIP, non-blocking scaffold today) is designed to be exactly that harness: beetroot build the Magisk image → beetroot up → wait for MagiskSU → exercise root-driven flows. Once Tier 2 boots the Magisk image reliably, this checklist (happy path, spaced/hostile filenames, sha256-refusal, multi-module batch, temp-cleanup) can run as CI assertions against a real magisk --install-module, and any divergence from the two-parse model gets folded back into the mocked tests — exactly as this issue asks.

Status: partially enabled (harness scaffolded + boot prerequisite solved); the actual real-device/real-Magisk validation run is still pending Tier 2 hardening. Not closing.

---

Generated by Claude Code