Anand Buddhdev
2020-May-27 15:48 UTC
[nsd-users] NSD still shows permission errors on Debian 10 Buster
On 27/05/2020 16:37, Simon Deziel via nsd-users wrote: Hi Simon,> As you saw, you need to add "ReadWritePaths=/var/log/" to the systemd > unit so that nsd can create the file. > > When you do so, on first startup, nsd changes UID from root -> nsd and > then creates /var/log/nsd.log: > > root at d10-nsd:~# ls -l /var/log/nsd.log > -rw-r--r-- 1 nsd nsd 151 May 27 14:15 /var/log/nsd.log > > On subsequent starts, nsd checks if it can append to the log while still > running as root. I believe this is a bug as this check should happenAre you certain of this? I have never seen any errors on my NSD systems.> after the switch from root->nsd. You can workaround it by using the big > hammer that is CAP_DAC_OVERRIDE [*] or add this with `systemctl edit nsd`: > > [Service] > ExecStartPre=-/bin/chown --quiet root:root /var/log/nsd.logAll of this seems to be band-aid upon band-aid of unnecessary hacks.> As for the failed unlinking of the pidfile, this is harmless and should > not be logged as a warning. It may already be fixed in newer releases as > it was done with Unbound already.PID files are so pass?! They are irrelevant on systems where daemons are run under supervisors. I would highly recommend setting "pidfile" to "" in nsd.conf. This prevents creation of a PID file. Systemd already knows the PID of the NSD process, and can signal it directly. Regards, Anand
Wouter Wijngaards
2020-May-27 15:52 UTC
[nsd-users] NSD still shows permission errors on Debian 10 Buster
Hi, On 27/05/2020 17:48, Anand Buddhdev via nsd-users wrote:> On 27/05/2020 16:37, Simon Deziel via nsd-users wrote: > > Hi Simon, > >> As you saw, you need to add "ReadWritePaths=/var/log/" to the systemd >> unit so that nsd can create the file. >> >> When you do so, on first startup, nsd changes UID from root -> nsd and >> then creates /var/log/nsd.log: >> >> root at d10-nsd:~# ls -l /var/log/nsd.log >> -rw-r--r-- 1 nsd nsd 151 May 27 14:15 /var/log/nsd.log >> >> On subsequent starts, nsd checks if it can append to the log while still >> running as root. I believe this is a bug as this check should happen > > Are you certain of this? I have never seen any errors on my NSD systems.I tried to fix the contrib nsd.service by adding Simon's suggestion to it, if that is wrong let me know: https://github.com/NLnetLabs/nsd/commit/922d5a27f8b291b1157530cfde49707c134cf486 Also the unlink error message is fixed in the same manner as Unbound's printout; by silencing it to avoid chatter due to permission errors. It seems like NSD did manage to empty the file for MJ, but not unlink it. https://github.com/NLnetLabs/nsd/commit/bcc9b1107e1bc6a728f95c904db9603105a142ac Best regards, Wouter> >> after the switch from root->nsd. You can workaround it by using the big >> hammer that is CAP_DAC_OVERRIDE [*] or add this with `systemctl edit >> nsd`: >> >> [Service] >> ExecStartPre=-/bin/chown --quiet root:root /var/log/nsd.log > > All of this seems to be band-aid upon band-aid of unnecessary hacks. > >> As for the failed unlinking of the pidfile, this is harmless and should >> not be logged as a warning. It may already be fixed in newer releases as >> it was done with Unbound already. > > PID files are so pass?! They are irrelevant on systems where daemons are > run under supervisors. I would highly recommend setting "pidfile" to "" > in nsd.conf. This prevents creation of a PID file. Systemd already knows > the PID of the NSD process, and can signal it directly. > > Regards, > Anand > _______________________________________________ > nsd-users mailing list > nsd-users at lists.nlnetlabs.nl > https://lists.nlnetlabs.nl/mailman/listinfo/nsd-users
Simon Deziel
2020-May-27 17:02 UTC
[nsd-users] NSD still shows permission errors on Debian 10 Buster
On 2020-05-27 11:48 a.m., Anand Buddhdev wrote:> On 27/05/2020 16:37, Simon Deziel via nsd-users wrote: > > Hi Simon, > >> As you saw, you need to add "ReadWritePaths=/var/log/" to the systemd >> unit so that nsd can create the file. >> >> When you do so, on first startup, nsd changes UID from root -> nsd and >> then creates /var/log/nsd.log: >> >> root at d10-nsd:~# ls -l /var/log/nsd.log >> -rw-r--r-- 1 nsd nsd 151 May 27 14:15 /var/log/nsd.log >> >> On subsequent starts, nsd checks if it can append to the log while still >> running as root. I believe this is a bug as this check should happen > > Are you certain of this? I have never seen any errors on my NSD systems.I reproduced it all in a Debian Buster VM before posting. Are you using the same systemd unit as Debian Buster's [*] ?>> after the switch from root->nsd. You can workaround it by using the big >> hammer that is CAP_DAC_OVERRIDE [*] or add this with `systemctl edit >> nsd`: >> >> [Service] >> ExecStartPre=-/bin/chown --quiet root:root /var/log/nsd.log > > All of this seems to be band-aid upon band-aid of unnecessary hacks.That's a band-aid indeed. IMHO the proper fix is to be consistent in handling the file. So either open it as root and not chown it or always touch it after setuid().>> As for the failed unlinking of the pidfile, this is harmless and should >> not be logged as a warning. It may already be fixed in newer releases as >> it was done with Unbound already. > > PID files are so pass?! They are irrelevant on systems where daemons are > run under supervisors. I would highly recommend setting "pidfile" to "" > in nsd.conf. This prevents creation of a PID file. Systemd already knows > the PID of the NSD process, and can signal it directly.Would it make sense to simply ignore the pidfile directive when running through systemd? *: https://salsa.debian.org/dns-team/nsd/-/blob/nsd_debian/4.1.26-1/debian/nsd.service