containerd 2.1 hands sandbox pods a writable cgroup without the privileged flag

On its own, a read-write /sys/fs/cgroup is more dangerous than the read-only one it replaces: a container running as node root could write max into its own memory.max and step past its budget. ^[5] What keeps the containerd handler safe is runc. ^[6]

If a container gets both a private cgroup namespace and a writable cgroupfs, runc hands ownership of its cgroup to whichever host uid the container's uid is mapped onto, then chowns the delegate files - cgroup.procs, cgroup.subtree_control, memory.oom.group and the rest - to that same uid. memory.max keeps root as its owner. ^[6] Put the pod in its own user namespace with hostUsers: false and that owner is an unprivileged id. ^[7] systemd calls this Delegate=yes; here it is scoped to one pod. ^[8]

The author ran it on k3s 1.36.5, containerd 2.3.4, runc 1.4.2 and Linux 6.8. ^[9] Without the handler, a user-namespaced pod sees the mount read-only and owned by 65534, the host's root left unmapped. ^[10] On a RuntimeClass that carries the handler, the same pod gets the mount read-write and owned by its own root, while memory.max still reports 65534. ^[11]

Making this work takes more than the pod spec. The node needs a containerd drop-in that defines a runtime with cgroup_writable = true and SystemdCgroup = true, plus a RuntimeClass that points the pod at that handler. ^[14] runAsUser: 0 is root of the pod's user namespace only, so runc chowns the cgroup to whatever uid the container starts as, and mapping ids into each sandbox needs CAP_SETUID there. ^[15]

For networked sandboxes, the /dev/net/tun problem has a fix: the handler's base_runtime_spec adds the device as containerd's default OCI spec plus the device node, generated on the node. ^[17] A CI script runs the whole setup against a fresh k3s and checks that the pod is unprivileged and that a sandbox actually runs. ^[18]