Il giorno mer 20 apr 2022 alle 22:43:01 +02:00:00, Lennart Poettering
<lennart@xxxxxxxxxxxxxx> ha scritto:
Yes, use User=www-data + Group=www-data.
And then use the "!" modifier in ExecStart= to tell systemd that even
though the specified User=/Group= are the ones used by the service it
should leave set setuid() call to be done by the daemon itself. If
specified that way, systemd will invoke the main daemon binary as
root:root.
Oh, thanks! I didn't think about this. It almost fixes everything; the
logs were previously owned by www-data:adm, making them possible to
read by users part of the adm group, while now they're owned by
www-data:www-data. Am I forced to use something like `chown --recursive
www-data:adm /var/log/nginx` or do I have cleaner alternatives?
That said, are you sure you need to run the nginx binary as root? My
suspicion is that it would be much nixer if nginx would be fixed to
just be able to be invoked unprivileged (or at worst, with some very
limited ambient caps, such as CAP_NET_BIND_SERVICE).
As far as I know, yes. nginx has a master process that spawns
unprivileged worker threads that handle incoming requests, while the
master handles things like binding to ports 80 and 443 and setting up
TLS certificates, two actions that require elevated privileges. Reading
the certificate keys needs root privileges more than the other things;
making the key readable by www-data would be even worse, and giving the
CAP_DAC_OVERRIDE capability to an unprivileged nginx service would in
part defeat the purpose of not running it as root, as now worker
processes (more vulnerable than the master one) would be able to deal
grater damage if compromised.
But of course I'm not very experienced, so there might be a nice
solution that I completely ignore.
Thanks again for your tips :D
