<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 20, 2022, 23:43 Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mi, 20.04.22 22:18, Andrea Pappacoda (<a href="mailto:andrea@pappacoda.it" target="_blank" rel="noreferrer">andrea@pappacoda.it</a>) wrote:<br>
<br>
> Hi! I've been playing around with various options documented in<br>
> systemd.exec(5) recently, and I'm having an issue with `LogsDirectory=` and<br>
> its permissions.<br>
><br>
> In particular, I've tried setting `LogsDirectory=nginx` for nginx.service,<br>
> but it is now unable to write to the logs. This is because the nginx service<br>
> is started as root, and then drops its privileges to www-data (as I'm on<br>
> Debian). systemd can't know this, and chowns the /var/log/nginx directory to<br>
> root:root, making it impossible for nginx threads spawned as www-data to<br>
> write to them. It was previously set to www-data:adm<br>
><br>
> Is it possible to specify the owner and group of the `LogsDirectory` (or of<br>
> any other directory specified by similar options)?<br>
<br>
Yes, use User=www-data + Group=www-data.<br>
<br>
And then use the "!" modifier in ExecStart= to tell systemd that even<br>
though the specified User=/Group= are the ones used by the service it<br>
should leave set setuid() call to be done by the daemon itself. If<br>
specified that way, systemd will invoke the main daemon binary as<br>
root:root.<br>
<br>
e.g.<br>
<br>
    …<br>
    [Service]<br>
    ExecStart=!/usr/sbin/nginxd<br>
    User=www-data<br>
    Group=www-data<br>
    LogsDirectory=nginx<br>
    …<br>
<br>
That said, are you sure you need to run the nginx binary as root? My<br>
suspicion is that it would be much nixer if nginx would be fixed to<br>
just be able to be invoked unprivileged (or at worst, with some very<br>
limited ambient caps, such as CAP_NET_BIND_SERVICE).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Hmm, on the other hand: if nginx starts unprivileged and its log files (and TLS certificate files, and config files) are owned by www-data... and your webapps (e.g. php-fpm) are also running as www-data (as is very common), then an exploitable webapp could do a bit more damage than if the certs&logs were only accessible to root, e.g. they could scribble all over your past logs now.</div><div dir="auto"><br></div><div dir="auto">I usually don't mind services like httpd or postfix dropping privileges on their own because they can be more flexible about it, e.g. use different UIDs for different purposes.</div></div>