[systemd-devel] LogsDirectory= permissions

[Mantas Mikulėnas]

On Wed, Apr 20, 2022, 23:43 Lennart Poettering <lennart at poettering.net>
wrote:

> On Mi, 20.04.22 22:18, Andrea Pappacoda (andrea at pappacoda.it) wrote:
>
> > Hi! I've been playing around with various options documented in
> > systemd.exec(5) recently, and I'm having an issue with `LogsDirectory=`
> and
> > its permissions.
> >
> > In particular, I've tried setting `LogsDirectory=nginx` for
> nginx.service,
> > but it is now unable to write to the logs. This is because the nginx
> service
> > is started as root, and then drops its privileges to www-data (as I'm on
> > Debian). systemd can't know this, and chowns the /var/log/nginx
> directory to
> > root:root, making it impossible for nginx threads spawned as www-data to
> > write to them. It was previously set to www-data:adm
> >
> > Is it possible to specify the owner and group of the `LogsDirectory` (or
> of
> > any other directory specified by similar options)?
>
> 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.
>
> e.g.
>
>     …
>     [Service]
>     ExecStart=!/usr/sbin/nginxd
>     User=www-data
>     Group=www-data
>     LogsDirectory=nginx
>     …
>
> 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).
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220421/7e7d2647/attachment-0001.htm>