libct/cg/sd/v2: rely on systemd to set device access rules

[kolyshkin]

It seems that the code added by commit b810da1 had cgroup v1
in mind, where runc overwrites the rules set by systemd. It is all
different in v2, because both ebpf programs (systemd's and runc's) have
to say "allow" for the device to get access.

So, when using cgroup v2 with systemd cgroup driver, access to devices
rules for that can't be translated to systemd properties is not possible
at all, and it makes sense to error out (rather than warn) in such case,
as the container won't work as intended.

With this change in mind, provided that runc correctly translates all
the device access rule, and systemd correctly applies those, we no
longer have to create and apply a second eBPF program with own rules.
Let's stop doing that, instead relying on systemd only.

Having two sets of rules (two ebpf programs) for cgroupv2/ebpf is
problematic for two reasons:

1. Both sets should say "ok" for access to be granted.

2. After systemd daemon-reload (which happens during routine systemd
   upgrade) the program runc adds is removed, so it's a time-bomb.

Note 1: by the way, this difference in cgroup v1 vs v2 behavior explains failures seen in #3620, #3708, #3671.

Note 2: since this may be a breaking change (container won't run vs device won't be accessible), let's not backport this one, but make it part of runc 1.2.

[kolyshkin]

As for the systemd, cgroup v2 is the default since systemd v243 (and most distros reverted that). Meaning, if we're running on cgroup v2 + systemd, we can assume systemd is at least at v243.

Also, here's the list of distros having cgroup v2 by default, and their respective systemd versions.

Distro	oldest systemd version	source of info
Fedora (since 31)	243	http://mirror.math.princeton.edu/pub/fedora-archive/fedora/linux/releases/31/Everything/source/tree/Packages/s/
Arch Linux (since April 2021)	248	https://wiki.archlinux.org/index.php?title=Cgroups&diff=next&oldid=653999
openSUSE Tumbleweed (since c. 2021)	?
Debian GNU/Linux (since 11)	247	https://packages.debian.org/bullseye/systemd
Ubuntu (since 21.10)	248	https://launchpad.net/ubuntu/+source/systemd/248.3-1ubuntu4
RHEL and RHEL-like distributions (since 9)	249	https://git.centos.org/rpms/systemd/history/SPECS/systemd.spec?identifier=c9-beta

[kolyshkin]

Based on the info from the previous comment, it does not make sense to check for minimal systemd version in systemd+cgroup v2 driver, as it will be > v240 in any case.

[kolyshkin]

@opencontainers/runc-maintainers @cyphar PTAL

[kolyshkin]

@cyphar what do you think about this? In my view, this fixes the mess of duplicate bpf programs.

The alternative is to switch to using BPFPprogram= property, but it requires systemd >= v249 which is somewhat new, meaning we'll have to keep all this device rule conversion code, too, for quite some time. Meaning, it's needed anyway.

[kolyshkin]

Rebased, ptal @cyphar @AkihiroSuda

[thaJeztah]

Ubuntu (since 21.10)

Worth noting that Ubuntu 20.04 is still quite popular, although I don't know cgroups v2 on that one (not near a computer to check right now)

[cyphar]

Surely we don't want to always return an error in this case, even if systemd supports it? I guess it's more consistent but now we're going to start returning errors...

[kolyshkin]

This here is a combination of these four factors:

1. The rule is minor-wildcard (i.e. $MAJOR:*).
2. Systemd is older than v240 (so we can't use {block,char}-NNN syntax, where NNN == $MAJOR).
3. The MAJOR specified can't be found in /proc/devices (so we can't use {block,char}-NAME syntax, where NAME is an entry from /proc/devices corresponding to specified major number).
4. Cgroup is v2, meaning we solely rely on systemd for rules management (see the change to libcontainer/cgroups/fs2/fs2.go), meaning we can't enable access to these devices.

So, the two options we have are ignore this device rule (with a warning) or return an error. I'd rather do the latter since otherwise it's harder to debug cases when we can't access a device.

NOTE we do not return errors if we think systemd supports it.

[kolyshkin]

@cyphar It just occurred to me you meant we should still generate our own EBPF (in this case these errors might be downgraded to warnings).

Or do something else -- say, if there are no warnings when generating systemd device rules, skip adding our own EBPF, otherwise add one?

[kolyshkin]

I played with this a bit, checking a case when a rule is not added to systemd DeviceAccess, but only to the EBPF we generate. In this case kernel denies access to the device.

This essentially means:

• if we can't translate a device rule to systemd lingo, having our own EBPF won't help to allow access;
• if we can translate all the rules, and systemd is bug free™, having our own EBPF is redundant.

This is the reason why in this PR I chose to

• return an error if a rule can't be applied;
• not generate a second EBPF.

Now, we can certainly downgrade the errors to warnings, let me know if this is how you prefer it.

[kolyshkin]

@cyphar OK I've downgraded errors to warnings. PTAL.

[cyphar]

I'm going to move the milestone to 1.3.0. I'm not sure this is a critically needed fix for 1.2.0, and the fact (AFAICS) we could return errors for configurations that were previously allowed we probably should let the code stew in a 1.3.0-rc1 first.