Re: [systemd-devel] Waiting for (transient) hostname configuration
On 4/20/2022 1:09 PM, Alessio Igor Bogani wrote: # ExecStart=/usr/bin/Starter %H ExecStart=/bin/sh -c 'sleep 1; exec /usr/bin/Starter `hostname`' Is there a significant advantage to using the systemd macro over the backtick operator applied to the hostname program? Is the overhead of a spawned process really that expensive in this usage? If you're scrabbling for CPU cycles, you might be better off writing everything in C and using low-level kernel APIs. But I suspect that's not the case here.
Re: [systemd-devel] LogsDirectory= permissions
Il giorno mer 20 apr 2022 alle 22:43:01 +02:00:00, Lennart Poettering 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
Re: [systemd-devel] LogsDirectory= permissions
On Do, 21.04.22 06:36, Mantas Mikulėnas (graw...@gmail.com) wrote: > > 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 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. Well, things like postfix kinda replicate their own service manager. I have the suspicion it would be better to just leave that to systemd... Lennart -- Lennart Poettering, Berlin
[systemd-devel] Antw: [EXT] Re: Waiting for (transient) hostname configuration
>>> Alessio Igor Bogani schrieb am 20.04.2022 um
>>> 22:09
in Nachricht
:
...
> The %H specifier in the commented ExecStart always returns
> "localhost". The following ExecStart is my workaround to have the
I wonder whether a future version could interpret "\%H" as "substitute %H when
it's used, not when it was parsed the first time" ("%%" is in use already).
> hostname provided by DHCP (in the first version it was a while loop
> but a sleep works anyway and make things less convoluted).
>
> Ciao,
> Alessio
