Hi,
On 2024-06-29 22:21, Christian Kastner wrote:
At the moment, rootless Podman would seem like the obvious choice. As
far
as I'm aware, it has the same user namespaces requirements as the
unshare
backends in mmdebstrap, autopkgtest and schroot (user namespaces
enabled,
setuid newuidmap, 65536 uids in /etc/subuid, 65536 gids in
/etc/subgid).
As a datapoint, I use rootless podman containers extensively both for
autopkgtest and as an sbuild backend (though the latter is affected by
#1033352 for which I still need to implement a cleaner workaround).
I think the only problem I encountered was a corner case when passing
in
a device into a container: at some point, autopkgtest runs su which
uses
the setgroups() syscall, and group permissions get lost. The solution
was to setup up the proper gidmaps. I documented my findings here [1].
Though this latter issue shouldn't be a problem on buildds, where
devices aren't passed in.
How well does this setup nest? I had a lot of trouble trying to run the
unshare backend within an unprivileged container as setup by
systemd-nspawn - mostly with device nodes. In the end I had to give up
and replaced the container with a full-blown VM. I understand that some
of the things compose a little if the submaps are set up correctly, with
less IDs allocated to the nested child. Is there a way to make this work
properly, or would you always run into setup issues with device nodes at
this point?
Specifically I'm concerned about what this means for tests and if they
should be able to use unprivileged containers themselves to test things.
I guess we made the decision that we just assume "root" for testing. But
right now you could - presumably - also setup more things under that
assumption that would not work in an unprivileged setup. Is that a
problem?
Relatedly it'd be great if we actually had a VM in-between us and the
build. But that only works well on some architectures, only composes
well on even less (e.g. arm64 not having nested virtualization yet), and
only provides a marginal benefit if you execute the build outside of the
VM as well. But it'd shield us more from supply chain issues.
Kind regards
Philipp Kern
