[kim-em]

This PR adds a lake-check-sandbox input choosing how to make lake check's bubblewrap sandbox able to start on a runner that will not otherwise permit it. It stacks on #190 — feat: add lake-check input for sandboxed independent kernel checks, and should be reviewed after it.

GitHub-hosted runners restrict the unprivileged user namespaces bubblewrap needs, so lake-check fails there until something grants them. Granting them means changing the runner, which lean-action will not do uninvited, so the input takes "none" (the default, change nothing), "apparmor", "sysctl" or "setuid". Whichever is chosen is applied only when the sandbox has been probed and found not to work, so a runner that already permits user namespaces is left untouched.

"apparmor" is the narrowest and the documented choice. Ubuntu's restriction denies unprivileged user namespaces to programs whose AppArmor profile does not grant userns, so a profile covering bubblewrap leaves the restriction in force for every other program, where "sysctl" relaxes it runner-wide and "setuid" leaves a setuid binary behind. Measured on ubuntu-latest: all three make the sandbox work, and under "apparmor" and "setuid" the sysctl stays at 1.

Because these operations are privileged, they act only on a root-owned distribution bubblewrap at /usr/bin/bwrap or /bin/bwrap, never on a symlink, and never on an executable named by COMPARATOR_BWRAP. Without those guards, PATH or that variable would decide which file gets made setuid root or gains an AppArmor policy. Refusing a non-root owner also matters in its own right: chmod u+s on a file owned by the job user grants that user's privileges rather than root's, so it would leave the sandbox broken while appearing to have worked.

None of these changes is undone afterwards. The warnings and the documentation say so, because on a persistent self-hosted runner they outlive the job, and such runners are better configured once by their administrator with this left at "none".

The sandbox probe now exercises the namespace and mount operations Lake itself uses rather than a bare bind, since a runner can permit --ro-bind and still refuse the sandbox Lake actually builds.

A functional test runs paranoid on ubuntu-latest under "apparmor", so the option the documentation recommends is the one CI exercises.

🤖 Prepared with Claude+Codex

[austinletson]

I'd propose leaving the sandbox setup to users rather than doing it in the action. As far as I know, it's unusual for an action to relax a runner's security restrictions, and doing so here means lean-action takes on ~90 lines of privileged code that has to keep up with runner images, when one line in the user's workflow does the same thing transparently. Since lake-check is opt-in (it's not in the workflow lake new generates), I think it's reasonable to ask users to add the snippet from #190's README, as long as the README makes this very clear.

What do you think?