cgroup ownership (delegation chown) is only implemented in the systemd cgroup manager, not the fs driver

[eplightning]

The OCI runtime-spec "cgroup ownership" semantics (chown the container's cgroup to the host UID mapping container root, when the container has a private cgroup namespace and cgroupfs is mounted rw) are only implemented for the systemd cgroup driver. With the default fs driver, the cgroup is left owned by init-ns root, so a userns container gets an rw cgroupfs mount whose files are all owned by an unmapped user (nobody:nogroup) and cannot use the delegation it was seemingly granted.

This makes containerd's cgroup_writable CRI option (containerd 2.1+) non-functional for hostUsers: false Kubernetes pods on any host using the fs driver - e.g. distros without systemd (Talos Linux), where the systemd driver is not available at all.

I imagine more users will run into this, given that this flag (cgroup_writable) will soon land in Kubernetes's securityContext as well.

Relevant chunk of code:

cgroups/systemd/v2.go

Lines 368 to 387 in bedc048

	if c.OwnerUID != nil {
	// The directory itself must be chowned.
	err := os.Chown(m.path, *c.OwnerUID, -1)
	if err != nil {
	return err
	}
	filesToChown, err := cgroupFilesToChown()
	if err != nil {
	return err
	}
	for _, v := range filesToChown {
	err := os.Chown(m.path+"/"+v, *c.OwnerUID, -1)
	// Some files might not be present.
	if err != nil && !errors.Is(err, os.ErrNotExist) {
	return err
	}
	}
	}