Package: autopkgtest
Version: 5.28
Severity: wishlist
Control: affects -1 + src:mmdebstrap src:debvm
X-Debbugs-Cc: jo...@debian.org
Hi,
Paul asked me to take this to email and he's probably right. Johannes
Schauer repeatedly tried to test mmdebstrap --mode=unshare in
autopkgtests and reportedly this fails. The most recent failure
reportedly happened three days ago in experimental, but retrieving
experimental logs turns out to be difficult.
What is needed to make this work? mmdebstrap --mode=unshare requires the
following features:
* unprivileged unsharing of user namespaces
- This is prohibited on DSA machines via a sysctl
- It works on most other systems
- Test case: unshare -U true
* A subuid allocation in /etc/subuid
- Allocated by default during user creation
- Test case: grep -q ^$(id -un): /etc/subuid
* subuid allocation must be mapped by container technology (if any)
- I suppose the unshare backend fails this. Likely also unprivileged
podmand.
* It must be possible to mount proc in the unshared user+mount+pid
namespace.
- This should always work but may be restricted by the container
technology for some reason.
- Test case: unshare -U -m -p -f -r --mount-proc true
- Paul tried this in the operational lxc containers. Successfully.
- I tried this in a local autopkgtest-unstable lxc container.
Successfully (unprivileged).
- Johannes reported that this would be the step that fails.
* Maybe more, but I don't know what would be missing. Maybe Johannes
knows.
In this bug, I ask for a new restriction and propose calling it
"needs-userns". It should cover the aspects mentioned above (probably in
more precision).
How does this apply to backends?
* chroot/schroot: Unsure. Maybe it works, maybe not.
* docker/podman: If unprivileged, it very likely does not work as the
user as the user running it would need at least two subuid ranges,
which is not the default and the container technology would have to
map the second subuid range to the subuid range of the test user. If
privileged, it might work (like lxc).
* lxc/lxd: Our testing indicates that this works.
* qemu: Any kind of VM-based backend probably just works.
* unshare: This very much is like unprivileged docker/podman and very
likely does not work.
What packages would use this beyond mmdebstrap? I see at least
chromium's sandbox using user namespaces for isolation (though with less
required features). Adoption of user namespaces will probably grow.
So initially, it could be as simple as adding this restriction and
statically saying that it is supported by lxc/lxd/qemu and nothing else.
The other part probably is figuring out how to make it work, which may
be either mmdebstrap bugs or missing features on debci, but diagnosing
this is evidently hard.
A number of tests that would benefit from this capability can be run
with needs-root or fakechroot (when it works) instead.
Helmut
