On Tue, 12 Jun 2018 at 17:18:34 +0100, Ian Jackson wrote:
> Hans-Christoph Steiner writes ("Bug#901030: some context"):
> > I agree that there can't be a Restriction for every config under the
> > sun.
Having tests be able to probe for their own requirements and declare
themselves to have been skipped, as they could in Automake (exit 77)
or TAP (print "1..0 # SKIP ${details}"), would be one way out of that.
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/20
proposes a "skippable" restriction, which means: if the test script
exits 77, it is to be treated as skipped rather than failed.
> > As for the binfmt_misc module discussion, I know nothing about how that
> > works. If you can fix this issue in the kernel, fine by me.
>
> ISTM that the bug is that the binfmt thing is not properly virtualised
> by containers. We don't have to fix that in the kernel; we could
> bodge it by installing binfmt-misc in the host.
Reference on binfmt_misc:
https://www.kernel.org/doc/html/v4.17/admin-guide/binfmt-misc.html
Briefly, it's a way to tell the kernel to treat particular (binary) file
contents in executable files as though they were #! lines for particular
interpreters.
I think there are two aspects of namespace-awareness ("virtualization"
for containers) that matter here:
- The fact that the binfmt_misc kernel module was loaded is not
namespaced, and in any case only the host system can load modules for
the obvious security reasons, so the kernel module has to be enabled
in the host, not the container. That's relatively non-problematic.
- The registrations ("executables matching pattern X are executed by
interpreter Y") are not namespaced, so it would be unsafe to allow
processes in a container to create new registrations: if they could,
then they could register "executables resembling ELF binaries are
executed by /bin/rm" and the host system would eventually delete
itself. That's a showstopper.
So I think tests that rely on binfmt_misc are always going to require
Restrictions: isolation-machine, unless/until the kernel can be made to
keep a separate table of binfmt_misc (pattern -> interpreter) mappings
for each "container" (in kernel terms, for each mount namespace or user
namespace or some new namespace type). That does not seem likely to
happen any time soon.
smcv
