Guard Cgroups against non-existent path

[incaseoftrouble]

https://github.com/sosy-lab/benchexec/blob/6467aa5e1117155586f50928c17097fa87f341de/benchexec/cgroupsv2.py#L223-L234 Here should be a check that the cgroup actually exists. The path could be non-existent if someone overlays the wrong cgroupfs in a container.

For example, if I create a docker container, it will have /system.slice/docker-....slice/ as root cgroup (if private cgroup namespace is enabled, which is the default), but if I then also add /sys/fs/cgroup as a mount into the container, the paths will be wrong: a cgroup /sys/fs/cgroup/group created in the container will have the path ../../group (since the root process of the container is in /sys/fs/cgroup/system.slice/docker-...)

(This is a minor point but also simple to add :) )

[PhilippWendler]

Yes, I want to detect this situation and tell users to not bind-mount cgroups into containers with cgroups v2. (You are not the first to attempt this.)

However, on my system (Ubuntu 22.04) I cannot reproduce to test my implementation:

$ sudo docker run --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:rw python:3.11 cat /proc/self/cgroup
0::/

What is the exact command that produces a cgroups file with ../ in it?

[incaseoftrouble]

sudo docker run --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:rw debian:bookworm-slim
root@eff463b34d64:/# mkdir /sys/fs/cgroup/test
root@eff463b34d64:/# bash -c 'echo "Hi I am $$"; echo $$ >> /sys/fs/cgroup/test/cgroup.procs; cat /proc/self/cgroup'
  Hi I am 8
  0::/../../test
rmdir /sys/fs/cgroup/test

Basically anything that moves you into a cgroup that is not a sub-cgroup of the docker container's private cgroup