add cgroup support via systemd-run

[xi]

So far, d-run concentrates on namespaces. However, there are more building blocks to containers. An important one is cgroups.

Cgroups (control groups) allow to set resource limits for processes. The cgroup of a process can be found by looking into /proc/{pid}/cgroup. They are managed via a special file system in /srs/fs/cgroup/ (spec). A cgroup is created by creating a folder in that subtree. Resource limits are set by writing to files in that folder. Cgroups can also be hierarchical. Who is allowed to create cgroups depends on the settings of the parent. On the root of the tree, only the root user can create cgroups.

Systemd uses cgroups extensively. It creates a cgroup under /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/ where user 1000 can create new cgroups. It also provides the systemd-run command that allows to create a cgroup with some properties, run a command in that cgroup, and then remove the cgroup again. As far as I understand, systemd-run --scope will communicate with the privileged systemd process to setup the cgroup, but will exec the container itself, so there is little chance of a privilege escalation. The available options for resource control are available at man systemd.resource-control.

The OCI container spec does not contain any metadata for resource control. However, it reserves some keywords that are used by the docker spec. They are quite limited though (only Memory, MemorySwap, and CpuShares).

This pull request proposes to use systemd-run to implement support for the three config options defined by docker. This follows the principal "Use established tools for the complicated bits".

However, I am not convinced:

• This would add an established, but still huge dependency (systemd)
• The restrictions defined by docker are not very granular. OCI doesn't even have resource limits. so I am not sure how useful this really is.
• I am not completely sure whether limiting CPU access is even possible for unprivileged users (the arch wiki talks about "delegation").
• I do not have a practical usecase right now.