Re: [systemd-devel] LogsDirectory= permissions
On Wed, Apr 20, 2022, 23:43 Lennart Poettering wrote: > On Mi, 20.04.22 22:18, Andrea Pappacoda (and...@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 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.
Re: [systemd-devel] Waiting for (transient) hostname configuration
On Wed, Apr 20, 2022 at 2:10 PM Alessio Igor Bogani wrote: > > Hi Lennart, > > On Wed, 20 Apr 2022 at 16:47, Lennart Poettering > wrote: > [...] > > > I use systemd-networkd and systemd-networkd-wait-online is enabled but > > > unfortunately it doesn't work anyway. > > If you don't mind I show you one of my Unit files: > > [Unit] > Description=Tango Starter service > Requires=network-online.target nss-lookup.target > Wants=tangorc.service > After=network-online.target tangorc.service nss-lookup.target > Conflicts=shutdown.target > RequiresMountsFor=/runtime > > [Service] > User=controls > Group=controls > # ExecStart=/usr/bin/Starter %H > ExecStart=/bin/sh -c 'sleep 1; exec /usr/bin/Starter `hostname`' > KillMode=process > RestartSec=5s > Restart=on-failure > > [Install] > WantedBy=multi-user.target I think the part you may have missed is you need something to run systemctl daemon-reload after networking is available but before your units are started. There are a couple ways to do that. One is to add your own unit that has After=network-online.target and simply has ExecStart=/bin/systemctl daemon-reload. Then you're other real units like the one above would have Requires and After on the unit that runs daemon-reload. Another way suggested by Sietse would be to add a drop-in for systemd-networkd-wait-online.service that adds ExecStartPost=/bin/systemctl daemon-reload. Since that's already going to run before network-online.target, none of your other units have to change.
Re: [systemd-devel] LogsDirectory= permissions
On Mi, 20.04.22 22:18, Andrea Pappacoda (and...@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). Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Waiting for (transient) hostname configuration
Hi Lennart, On Wed, 20 Apr 2022 at 16:47, Lennart Poettering wrote: [...] > > I use systemd-networkd and systemd-networkd-wait-online is enabled but > > unfortunately it doesn't work anyway. If you don't mind I show you one of my Unit files: [Unit] Description=Tango Starter service Requires=network-online.target nss-lookup.target Wants=tangorc.service After=network-online.target tangorc.service nss-lookup.target Conflicts=shutdown.target RequiresMountsFor=/runtime [Service] User=controls Group=controls # ExecStart=/usr/bin/Starter %H ExecStart=/bin/sh -c 'sleep 1; exec /usr/bin/Starter `hostname`' KillMode=process RestartSec=5s Restart=on-failure [Install] WantedBy=multi-user.target > What doesn't work precisely? The %H specifier in the commented ExecStart always returns "localhost". The following ExecStart is my workaround to have the 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
Re: [systemd-devel] Waiting for (transient) hostname configuration
Be very careful about inserting daemon-reload in the boot process, especially early. At best it will cause slow-downs, at worst lock ups. On Wed, 2022-04-20 at 13:18 +, Sietse van Zanen wrote: > Why not add: > > ExecStartPost=systemctl daemon-reload > > to systemd-networkd-wait-online.service? > > > -Sietse > > > From: systemd-devel on behalf > of Alessio Igor Bogani > Sent: Wednesday, April 20, 2022 12:54:11 PM > To: Lennart Poettering > Cc: systemd-devel@lists.freedesktop.org > Subject: Re: [systemd-devel] Waiting for (transient) hostname configuration > > Hi Lennart, > > On Tue, 19 Apr 2022 at 11:41, Lennart Poettering > wrote: > [...] > > the unit files are *loaded*, i.e. typically at earliest boot, long > > before they are actually *started*. Thus, if you change the hostname > > I understand now. It was the evaluation time of the specifier that I > have missed. I have just realized that my question was dumb, sorry for > that. > > [...] > > use. If you use systemd-networkd, then the > > sytemd-network-wait-online.service is what you want to use. If you > > enable that then network-online.target should be the point where DHCP > > is acquired and thus also the hostname in effect. > > I use systemd-networkd and systemd-networkd-wait-online is enabled but > unfortunately it doesn't work anyway. I have also tried to request > systemd to execute systemd-hostnamed "Before = nss-lookup.target" (*) > without success. > I left the little shell script inside to ExecStart to solve my problem > waiting for a better solution. > > Thanks Lennart for time, consideration and kindness. > > Have a nice and safe day! > > Ciao, > Alessio > > (*) All my Units use "After = network-online.target nss-lookup.target" > > signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] Waiting for (transient) hostname configuration
On Mi, 20.04.22 12:54, Alessio Igor Bogani (alessio.bog...@elettra.eu) wrote: > > the unit files are *loaded*, i.e. typically at earliest boot, long > > before they are actually *started*. Thus, if you change the hostname > > I understand now. It was the evaluation time of the specifier that I > have missed. I have just realized that my question was dumb, sorry for > that. Not at all. > > use. If you use systemd-networkd, then the > > sytemd-network-wait-online.service is what you want to use. If you > > enable that then network-online.target should be the point where DHCP > > is acquired and thus also the hostname in effect. > > I use systemd-networkd and systemd-networkd-wait-online is enabled but > unfortunately it doesn't work anyway. What doesn't work precisely? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Waiting for (transient) hostname configuration
Why not add: ExecStartPost=systemctl daemon-reload to systemd-networkd-wait-online.service? -Sietse From: systemd-devel on behalf of Alessio Igor Bogani Sent: Wednesday, April 20, 2022 12:54:11 PM To: Lennart Poettering Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Waiting for (transient) hostname configuration Hi Lennart, On Tue, 19 Apr 2022 at 11:41, Lennart Poettering wrote: [...] > the unit files are *loaded*, i.e. typically at earliest boot, long > before they are actually *started*. Thus, if you change the hostname I understand now. It was the evaluation time of the specifier that I have missed. I have just realized that my question was dumb, sorry for that. [...] > use. If you use systemd-networkd, then the > sytemd-network-wait-online.service is what you want to use. If you > enable that then network-online.target should be the point where DHCP > is acquired and thus also the hostname in effect. I use systemd-networkd and systemd-networkd-wait-online is enabled but unfortunately it doesn't work anyway. I have also tried to request systemd to execute systemd-hostnamed "Before = nss-lookup.target" (*) without success. I left the little shell script inside to ExecStart to solve my problem waiting for a better solution. Thanks Lennart for time, consideration and kindness. Have a nice and safe day! Ciao, Alessio (*) All my Units use "After = network-online.target nss-lookup.target"
Re: [systemd-devel] Waiting for (transient) hostname configuration
Hi Lennart, On Tue, 19 Apr 2022 at 11:41, Lennart Poettering wrote: [...] > the unit files are *loaded*, i.e. typically at earliest boot, long > before they are actually *started*. Thus, if you change the hostname I understand now. It was the evaluation time of the specifier that I have missed. I have just realized that my question was dumb, sorry for that. [...] > use. If you use systemd-networkd, then the > sytemd-network-wait-online.service is what you want to use. If you > enable that then network-online.target should be the point where DHCP > is acquired and thus also the hostname in effect. I use systemd-networkd and systemd-networkd-wait-online is enabled but unfortunately it doesn't work anyway. I have also tried to request systemd to execute systemd-hostnamed "Before = nss-lookup.target" (*) without success. I left the little shell script inside to ExecStart to solve my problem waiting for a better solution. Thanks Lennart for time, consideration and kindness. Have a nice and safe day! Ciao, Alessio (*) All my Units use "After = network-online.target nss-lookup.target"
Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] Waiting for (transient) hostname configuration
On Mi, 20.04.22 08:16, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > >> Is there a better way? > > > > First of all: % specifiers (including %H) are resolved at the moment > > the unit files are *loaded*, i.e. typically at earliest boot, long > > That's quite some surprise: I thought they are evaluated when they are > executed (as in shell scripts). > Is there a way to "reload" a specific unit file? No. You can only reload them all at once, via "systemctl daemon-reload". Lennart -- Lennart Poettering, Berlin
[systemd-devel] Antw: [EXT] Re: [systemd‑devel] Waiting for (transient) hostname configuration
>>> Lennart Poettering schrieb am 19.04.2022 um 11:41 in Nachricht : > On Di, 19.04.22 11:14, Alessio Igor Bogani (alessio.bog...@elettra.eu) wrote: > >> Dear systemd developers, >> >> Sorry for my very bad english. > > Not bad at all. > >> We use the hostname provided by DHCP to start the right subset of our >> applications on each of our machines (in other words the transient >> hostname is used as predictable machine identifier). >> >> Make it works on the ancient SysV is straightforward but I can't find >> a (reasonable) way to achieve the same goal with systemd. We already >> use both "Requires" and "After" with "network‑online.target >> nss‑lookup.target" into our units but it isn't enough. When our units >> start they obtain "localhost" from %H specifier. We don't find a way >> to wait for (transient) hostname to be configured. The only solution >> that it seems to work is to replace our binary in ExecStart with a >> script which make a busy‑loop until `hostname` output doesn't differ >> from "localhost". >> >> Is there a better way? > > First of all: % specifiers (including %H) are resolved at the moment > the unit files are *loaded*, i.e. typically at earliest boot, long That's quite some surprise: I thought they are evaluated when they are executed (as in shell scripts). Is there a way to "reload" a specific unit file? > before they are actually *started*. Thus, if you change the hostname > and want %H to resolve to that, you need to issue a reload at the > right moment, i.e. issue `systemctl daemon‑reload` once the hostname > is acquired. > > If your hostname is set via DHCP you need to wait for DHCP to be > acquired. How that's done, depends on the networking solution you > use. If you use systemd‑networkd, then the > sytemd‑network‑wait‑online.service is what you want to use. If you > enable that then network‑online.target should be the point where DHCP > is acquired and thus also the hostname in effect. > > Lennart > > ‑‑ > Lennart Poettering, Berlin
