Open peterhoeg opened 6 years ago
similar: libvirtd
currently runs qemu
as root, see #37281
I will take a look a munge. It is mainly used as authenticator for slurm. As an application in the category "security" it should maybe not run a root :/
@peterhoeg sorry, I didn't realize the merge would close this.
No problem. And thanks @markuskowa for sorting out munge.
I see all the graphite services define User = "graphite"; Group = "graphite";
so I'll check that off your list.
EDIT: although most services have a preStart
which is running as root right? Unchecking again...
I'm not realistically going to have enough time for getting this fully sorted in time for 18.09 - if anybody wants to push this forward, please do!
Please add the httpd service to the list. Tracked in https://github.com/NixOS/nixpkgs/pull/56304.
FYI: lighttpd supports systemd socket activation if lighttpd.conf contains server.systemd-socket-activation = "enable"
For typical usage of lighttpd, listening on a privileged port is the only root-level privilege that lighttpd needs at startup. Another option is to have the firewall redirect the privileged port to a high port on which lighttpd can listen without needed to start with root.
@gstrauss a fairly common pattern is to use capabilities in this case:
services.lighttpd.serviceConfig.AmbientCapabilities = mkIf (cfg.port < 1024) "cap_net_bind_service";
Nice. So are there any other questions/limitations about running lighttpd as non-root inside nixos? (I am lighttpd developer, and as you can see, clearly not a nixos expert)
There really shouldn't be anything special about running services as non-root under NixOS specifically. We're pretty tightly tied to the systemd ecosystem so the question really should be about running lighttpd as non-root under systemd.
NixOS allows us to be a little smarter about the unit files we generate (such as conditionally granting capabilities based on configuration).
My understanding is that the RecommendWay(tm) is to have systemd take care of setting up the environment and therefore change user before launching the service. Ideally if the service can be run with DynamicUser = true then do that.
gitlab fix: bcfa59bf822dc696e963d7abccfdff2e58e70525
Further to #41017, a number of daemons are currently running as root either through the entire life-time of the daemon or in order to do initialization at start and then dropping privs later. Instead we should use the infrastructure we have available to simply have the daemons run as unprivileged users right from the get-go: