On Fri, Feb 26, 2021 at 12:52 AM Peter Boy <pboy(a)uni-bremen.de> wrote:
Question to our Fedora Server QA experts.
There are 2 annoying selinux bugs:
They prevent the automatic start of systemd-nspawn containers.
A distinguishing feature of Server is universality and adaptability to local
requirements. Hence the support of not only one mainstream container solution, but also
alternatives (and especially annoying, with Debian selinux it works).
"The default system init daemon (e.g. systemd) must be capable of
starting, stopping, enabling and disabling correctly-defined
If Server Edition uses or intends to use systemd-nspawn to initiate
system services, and selinux avc denials are interfering in this, it
might be a violation of this criterion. This is an aggressive
argument. The criterion explicitly excludes the case were some system
services are broken. The intent is to provide for working init, i.e.
systemd itself. But depending on the usage of systemd-nspawn to
provide services, it could be argued systemd-nspawn is not merely an
adjunct to systemd but an integral part of system initialization.
"Bug hinders execution of required Beta test plans or dramatically
reduces test coverage"
If systemd-nspawn can't run at all due to avc denials, it's plausible
it reduces your test coverage. But do you have tests covering
systemd-nspawn? There is an equivalent final release requirement.
This is specific to system services. If they're enabled by default
they have start, they can't fail. If you have any services that depend
on systemd-nspawn, they certainly are covered here.
These don't apply to Server Edition, but you could have equivalents of
them. Is systemd-nspawn basic functionality for Server Edition? In
fact, I wonder if this is too weak of an argument and whether there
is, or should be, a general release criterion that covers default
installed container managers. Right now only IoT covers this:
i.e. I wonder if there should be a Fedora wide beta release
requirement: "It must be possible to deploy a container image using a
default installed container manager in a release blocking image."
Currently that's systemd-nspawn and podman.
I mean, why should it ship in a broken state on Workstation? Let alone
Server or IoT?
You can work around these bugs easily following the usual SELinux
troubleshooting procedure. You have to add 5 or 6 rules.
What's the problem with pushing these rules in an update for both 33 and 34?