The fallback candidate relies on the setuid newuidmap/newgidmap helpers
(uidmap package) plus a subuid/subgid range for the current user. Note in
the candidate docs that the startup probe rejects the candidate when those
are missing, so the plain --map-root-user form is used instead.
Plain `unshare --user --map-root-user` fails on kernels and containers
that block unprivileged writes to /proc/self/uid_map (e.g. GitHub Actions,
restricted AppArmor profiles). On those systems util-linux delegates to the
setuid newuidmap/newgidmap helpers when --map-auto is also present.
Add the combined form as a fallback candidate and build the launcher args
from the probed mapping, so systems without newuidmap/newgidmap or a
/etc/subuid range keep using the plain form.
No behavior change. Move the inline probe out of
unshare_user_namespace_works into a reusable unshare_probe helper and a
cached working_unshare_mapping() that picks the first working candidate
from UNSHARE_MAPPING_CANDIDATES, so the launcher and the capability probe
share one code path.
On GitHub Actions runners, `unshare` binary exists at /usr/bin/unshare
but user namespaces (CLONE_NEWUSER) are restricted, causing `unshare
--user --map-root-user` to silently fail. This produced empty stdout
in the bash_stdout_roundtrip parity test (mock_parity_harness.rs:533).
Replace the simple `command_exists("unshare")` check with
`unshare_user_namespace_works()` that actually probes whether
`unshare --user --map-root-user true` succeeds. Result is cached
via OnceLock so the probe runs at most once per process.
Fixes: CI red on main@85c5b0e (Rust CI run 23933274144)
linkst
bellman
Jobdori
Yeachan-Heo