On Mon, 01 Jul 2024 at 09:18:19 +0200, Philipp Kern wrote:
> Specifically I'm concerned about what [advocating use of podman]
> means for tests and if they
> should be able to use unprivileged containers themselves to test things.
tl;dr: There's no regression here, because you already can't run those
tests on a buildd.
There's no unified definition of "container" in the Linux kernel, only
a selection of different mechanisms that are used by container managers
to do what they want to do according to their individual security models
and desired functionality, so the only fully general answer we can give
to this is: there are containers, and there are containers, so you'll
need to be more specific about which specific things you want.
One use-case that I'm familiar with is bwrap (bubblewrap, as used by
flatpak) nested inside podman. bwrap is a relatively limited container
technology with relatively "light" requirements, at the cost of imposing
harsh restrictions on the code inside the container: you only get access
to one uid, and all other uids get mapped to the overflow uid ("nobody).
You can think of as having two possible identities, "me" and "not me".
Even with that limitation, bwrap inside podman doesn't normally work,
because podman forbids most nested container operations. I'm unsure
whether this is a functional requirement to prevent attacks where the
podman container "payload" escapes from the container and gets arbitrary
code execution on the host, or whether this is merely non-essential
security hardening to make it harder to exploit possible vulnerabilities
that podman aims to already prevent in some other way. Either way,
I would expect that buildd operators would not want to allow it.
podman nested inside podman is "more difficult" than bwrap nested inside
podman (because it's more capable and imposes fewer restrictions on the
payload, therefore needs a larger-than-default block of uids to be made
available, whereas bwrap only needs one uid), and almost certainly also
won't work.
But neither of these is a regression, because we can't normally do either
of those things inside schroot anyway! So packages like bubblewrap and
flatpak have no choice but to skip most of their regression tests at
build-time. This is obviously not ideal, but it's better than not being
able to ship these packages in Debian at all.
On ci.debian.net, the bubblewrap and flatpak test suites are re-run as
"as-installed" tests, and those *can* be run, using autopkgtest's qemu
backend - although I believe that's currently disabled because of some
technical issues with the qemu backend or the infrastructure, so those
tests might end up being skipped (again) on the lxc backend.
I believe bwrap nested inside `podman --privileged` *does* work. As I
said above, I don't know where that falls on the scale between "believed
to be secure, but less well-hardened" and "definitely not secure".
> Relatedly it'd be great if we actually had a VM in-between us and the build.
Prior art for this includes `sbuild --chroot-mode=autopkgtest
--autopkgtest-virt-server=qemu` (which uses qemu instead of schroot
or podman as the "container" for the actual build), openSUSE's
Open Build Service (which uses a new VM for each build in at
least some configurations), and my own experimental build wrapper
<https://salsa.debian.org/smcv/vectis> (which runs the whole sbuild
instance inside the VM, in an attempt to be bug-for-bug compatible with
Debian's production infrastructure as mentioned earlier in this thread).
smcv
