Reliably using cgroups to prevent leaking (grand-)child processes from unprivileged programs #183
Unanswered
KJTsanaktsidis
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I'm often it seems writing programs that need to spawn child processes and make sure the children don't leave any sub-processes of their own lying around; think things like:
cgroups of course provides an almost perfect solution to this:
/proc/self/cgroups,/sys/fs/cgroup/my_cgroup/new-cgroup-abcforkandexecof the child program, have the child add itself tonew-cgroup-abc/cgroup.procsnew-cgroup-abc/cgroup.procsand kill them withnew-cgroup-abc/cgroup.kill/sys/fs/cgroup/my_cgroup/new-cgroup-abcdirectory(this doesn't fall afoul of the "no-internal-processes" rule because we set no resource limits or anything; we're purely using the cgroups for race-free process management here).
I say almost-perfect, because this requires the system administrator to have delegated the cgroup hierarchy to the service by chown'ing it to the user the service is running as (with
Delegate=in systemd, or via appropriate options with docker/podman).I guess the delegation by system administrator is required because it allows the process to muck around with resource assignments? However, it seems to me that this use-case of "I want to spawn a tree of children and reliably clean it up" isn't really something it makes sense to allow sysadmins to limit by policy; rather, this seems like it should be a universally available enhancement to the classic Unix process API.
I'm curious how other people are handling these sorts of use cases? Is there a better API I don't know about with less sysadmin overhead?
Beta Was this translation helpful? Give feedback.
All reactions