Managing a cgroup hierarchy from within a container- is root necessary? #20295
-
BackgroundI'm running a main process in a container that forks processes. I would like to apply separate resource limits to the forked processes (collective limits for all forked processes), so that if the forked processes exceed memory limits we don't kill the main process. The main process is not root. Are there recommendations for this? What I've investigatedBased on this https://systemd.io/CGROUP_DELEGATION/, I tried to run a podman container as a systemd service with cgroup v2 and Delegate=yes. My host has SELinux enabled, so I had to set container_manage_cgroup true. I also had to pass --systemd=always to podman run so that we mounted the cgroup filesystem in rw mode. I was able to create cgroups in /sys/fs/cgroup, but only as root user in the container. Using non-root user, even if I use the user specified in the systemd service file (which has rw permission on the service cgroup on the host), I get permission denied when trying to create a sub cgroup. QuestionIs root necessary to manage the cgroup hierarchy inside the container? Is there any config or setup that I'm missing below? my setupHost version: Fedora 36 I've tried to run this as a system service, as a user service, and also as a transient scope with systemd-run -p Delegate=yes --user --scope podman run --cgroupns=private --systemd=always --privileged --security-opt unmask=/sys/fs/cgroup --user 1001 docker.io/nginxinc/nginx-unprivileged. Below is my system service unit file [Service] [Install] |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
Bump, is there anything missing or incorrect in my setup, or possibly an issue with podman/systemd integration? |
Beta Was this translation helpful? Give feedback.
-
@giuseppe It looks like you've answered questions on this topic, could you please take a look when you get a chance? |
Beta Was this translation helpful? Give feedback.
you need to chown the cgroup before it is usable from a non-root user inside the container, since it is owned by root. You could set it up using an entrypoint in the container that does the chown and then change UIDs to the desired one.