Deploying the isolating runner took CI down for about two minutes, and this is the fix.
The runner refused to start — correctly, since it will not silently fall back to unsandboxed builds — with:
running `/usr/bin/newuidmap ...`: write to uid_map failed: Operation not permitted
Error: cannot set up namespace using "/usr/bin/newuidmap"
Rootless podman sets up its user namespace with newuidmap, a setuid helper.
NoNewPrivileges=yes blocks exactly that. The choice is between the flag and
running builds in containers at all.
The trade, stated rather than slipped in. NoNewPrivileges constrained a
process that was already executing arbitrary repository code as ci-runner. A
container confines that code to an image and a bind-mounted workspace, and the
build no longer runs in the runner process's context at all. The container is the
stronger boundary by a wide margin; what is lost is one layer on a process that
is ours rather than a build's. Under -isolation none there is no container and
the flag should stay on, which both the drop-in and the docs say.
A misdiagnosis worth recording. I first bisected the hardening flags and every
one passed individually, which pointed away from NoNewPrivileges. That was a
false negative: podman keeps a pause process, so once a namespace exists later
commands join it without calling newuidmap. After killing the pause process the
failure reproduced immediately and exclusively under NoNewPrivileges=yes. The
journal had the answer before the bisect did.
CI was restored in the meantime by pinning -isolation none in the deployed
drop-in — explicit and logged at start-up, not a silent fallback. make deploy-runner overwrites that file, so this merge and deploy replaces the hotfix
rather than layering on it.
Ref #144