[SELinux] cgroupv2: runc run --systemd-cgroup do not put container in proper cgroup

[kolyshkin]

runc ps not working when runc run --systemd-cgroup is used

# ../contrib/cmd/recvtty/recvtty -m null sock.sock &
# ./runc --systemd-cgroup run -d --console-socket sock.sock tees
# ../runc --systemd-cgroup list
ID          PID         STATUS      BUNDLE         CREATED                          OWNER
tees        26230       running     /vagrant/tst   2020-04-12T19:07:22.900616771Z   root
# ../runc --systemd-cgroup ps tees
UID          PID    PPID  C STIME TTY          TIME CMD
# ../runc ps tees
UID          PID    PPID  C STIME TTY          TIME CMD

Indeed, the process is not in the cgroup it is supposed to be in!

# cat /sys/fs/cgroup/system.slice/runc-tees.scope/cgroup.procs 
# cat /proc/26230/cgroup 
0::/system.slice/sshd.service

😮

Update: the cause was old(er) container-selinux package in Fedora 31 vagrant image. Once updated, it works. The problem, though, is that runc (or crun) do not see an error from systemd which can't create a transient unit.

[AkihiroSuda]

Is this a recent regression or depends on a specific config?

[kolyshkin]

Is this a recent regression or depends on a specific config?

Looks like it has always been that way. If you take a look at systemd's v1 manager (aka LegacyManager) Apply method, it calls joinCgroups() at the very end, and it will write the PID to all cgroups.

Same method for systemd v2 (aka UnifiedManager), it only calls createCgroupsv2Path but never writes pid. The code was different before my commit a949e4f (PR #2273), but it still was not doing what it should (and alas I overlooked it).

[kolyshkin]

Looks like it has always been that way.

Indeed it was, since the very beginning -- see commit 524cb7c (PR #2113).

[kolyshkin]

and since we were not doing any testing, this bug lived to the day.

Fix is easy though: #2311

[kolyshkin]

OK, the cause of the issue is vagrant image of Fedora 31 used for testing. It came with not-so-up-to-date container-selinux (or maybe selinux-policy?), which resulted in:

Apr 13 21:16:21 localhost.localdomain audit[1]: AVC avc: denied { setsched } for pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0
Apr 13 21:16:21 localhost.localdomain systemd[1]: runc-xoxo.scope: Failed to add PIDs to scope's control group: Permission denied
Apr 13 21:16:21 localhost.localdomain systemd[1]: runc-xoxo.scope: Failed with result 'resources'.
Apr 13 21:16:21 localhost.localdomain systemd[1]: Failed to start libcontainer container xoxo.

(same results with podman+crun).

This was fixed by dnf update -y container-selinux and is probably a known (and apparently fixed) bug.

The main issue here, though, is that the problem was not reported from systemd back to runc/crun. I don't know much about it but maybe we need to query the status afterwards?

[mrunalp]

@rhatdan Any thoughts ^ ?

[kolyshkin]

The main issue here, though, is that the problem was not reported from systemd back to runc/crun.

Which is a different problem, so I'll file a separate issue. This one can be closed.

[kolyshkin]

Filed #2313

TODO: file a similar bug for crun

[rhatdan]

Well the container-selinux not being updated could cause several problems.