Hi, I think there should be a declarative way to specify a module/service about process cgroups configurations as well as there is for systemd, nginx, firewall…
Aditionally the docs should talk about how default cgroups policies are applied by nixos.
Sorry if i do any mistake, I am a junior nixos user
There is! You use systemd’s resource control groups or the various per-service sandboxing settings. You can set them with the existing modules for declaratively configuring systemd units.
Cgroups aren’t “policies” per-se, in that they don’t apply automatically when a specific binary is executed. You need something to modify the cgroups of a running process. Given that NixOS is very focused on systemd, and systemd is in theory in charge of launching most things, systemd is the most appropriate place to do that.
If you wanted to start something that isn’t started by systemd, you could use bubblewrap, the usual container runtimes (lxc, podman, docker, etc.), or flatpak for desktop applications.
Bubblewrap can be declaratively configured with a script that can easily be created with NixOS modules, and the various container runtimes have existing modules. Flatpak does not currently have anything resembling a good module, but that’s mainly because flatpak doesn’t really offer a good interface for declarative configuration in the first place.
This too feels like a bit of a mismatch with how cgroups work. The default cgroup is simply what everything is launched in anyway; use host networking, PID space, user namespace, etc. Changing the “default” for these would effectively have no effect, because everything would remain in the same namespace, meaning you would have no isolation, making it pointless.
What could be documented is whether and what settings for various NixOS module systemd services are applied (e.g. for nginx). But I’m not sure that really provides much value over what’s simply in the source code - these settings should limit stuff to what is necessary for the service to work. You could document reasoning for each setting, but that’s better done in code comments that can be updated with the code.
You could document “profiles”, or which services have been “cgrouped”, or any suchlike. There have been small initiatives to do so, but everytime someone tries it becomes clear pretty quickly that each service is actually quite bespoke and doing this work downstream isn’t quite right, since we need input from upstreams on what their software actually needs. If you’re interested in following the discussion, the most recent thread on this topic was here, I think: Pre-RFC: Systemd Hardening