After recently upgrading to LXC/LXCFS 6.0.x from version 4.0.x, I have noticed the need to run Systemd based containers with cgroups mounted using mixed permissions, whereas before I was able to get by using ro. After doing so, I have been able to modify the resources for the container, from inside the container itself, by writing to /sys/fs/cgroup/ (i.e. memory.max). I have used a custom written memory allocator to test this, and lo and behold it was reflected on the host system. After trying out many things specified in the docs I wasn't able to come up with a solution, until I noticed that lxcfs remounts cgroups without the nsdelegate option. Doing so on my system immediately fixed the issue, where writes to the /sys/fs/cgroup/ directory return a "write error: Operation not permitted".

I run privileged containers as the root user on my host system which is a Gentoo OpenRC-based system. This is also the system on which I first noticed this behaviour. I have also replicated this issue on an Ubuntu Server 24.04 host (Systemd). I've only ran into this issue with Systemd containers (mainly Ubuntu machines, 20.04 and up). I've been able to run OpenRC based containers like Artix Linux using ro permissions for cgroups and dropped SYS_ADMIN capabilities. The same goes for Ubuntu 16.04, 18.04, and thus haven't had a problem regarding this with those containers. When trying to run Ubuntu 20.04 and up with cgroups:ro or dropped SYS_ADMIN caps, the container will fail to boot.

My question is, why doesn't lxcfs mount cgroups with nsdelegate? Especially considering that the builtin OpenRC script "/etc/init.d/cgroups" already does this, and lxcfs effectively remounts it without the nsdelegate option.

Steps to reproduce:

1. Start the LXCFS service
2. Create and run a Systemd container as the root user on the host
3. lxc-attach into the container
4. Perform a write operation to /sys/fs/cgroup/memory.max
5. Observe the newly changed memory limits (i.e. using free -h)