Hi Simon,

thanks for your fast answer.

It seems that you're right that NSD tries to open the files as root user – which seems is blocked by the restrictive nsd.service configuration. See also:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938987

So, I changed the owner of all the files to 'root:root' and added '/var/log' to 'ReadWritePaths'. Then NSD starts without any problems.

However, on the next startup I see that NSD always changes back the ownership of '/var/log/nsd.log' from 'root:root' back to the nsd user. This leads to following error message:
> Nov 24 18:48:05 ns2 nsd[1959]: [2019-11-24 18:48:05.896] nsd[1959]: error: Cannot open /var/log/nsd.log for appending (Read-only file system), logging to stderr

When I stop NSD, I get following messages:
> Nov 24 21:01:22 ns2 nsd[2168]: [2019-11-24 21:01:22.109] nsd[2169]: warning: signal received, shutting down...
> Nov 24 21:01:22 ns2 nsd[2168]: [2019-11-24 21:01:22.112] nsd[2169]: warning: failed to unlink pidfile /run/nsd/nsd.pid: Permission denied
> Nov 24 21:01:22 ns2 nsd[2168]: [2019-11-24 21:01:22.117] nsd[2168]: error: xfrd: Could not open file /var/lib/nsd/xfrd.state for writing: Permission denied

This is very confusing since /var/lib/nsd/xfrd.state still has root:root, while NSD created the /run/nsd/nsd.pid using nsd:nsd.

Kind Regards,
Kaulkwappe



From: Simon Deziel <si...@sdeziel.info>
Sent: Sunday, 24. Nov 2019 – 17:09 CET +0100
To: nsd-users@NLnetLabs.nl

Subject: Re: [nsd-users] Permission error after upgrade to Debian Buster (10.2)

Hi Kaulkwappe,

On 2019-11-24 10:41 a.m., Kaulkwappe wrote:
> Dear colleagues,
> 
> after upgrading from Stretch to Debian Buster (10.2) I get following error 
> message which blocks NSD (4.1.26) from starting:
> 
>  > Nov 24 16:18:40 ns2 nsd[989]: [2019-11-24 16:18:40.030] nsd[989]: error: 
> could not open zone list /var/lib/nsd/zone.list: Permission denied
>  > Nov 24 16:18:40 ns2 nsd[989]: [2019-11-24 16:18:40.032] nsd[989]: error: 
> could not read zonelist file /var/lib/nsd/zone.list
> 
> However, the permissions are all fine; they did not change during the update.
> 
> ls -l /var/lib/nsd/zone.list
>  > -rw-r--r-- 1 nsd nsd 1195 Nov  4 17:33 /var/lib/nsd/zone.list
> 
> I had a look into /lib/systemd/system/nsd.service:
> 
>  > [Unit]
>  > Description=Name Server Daemon
>  > Documentation=man:nsd(8)
>  > After=network.target
> 
>  > [Service]
>  > Type=notify
>  > Restart=always
>  > ExecStart=/usr/sbin/nsd -d
>  > ExecReload=+/bin/kill -HUP $MAINPID
>  > CapabilityBoundingSet=CAP_CHOWN CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID 
> CAP_SETUID CAP_SYS_CHROOT
>  > MemoryDenyWriteExecute=true
>  > NoNewPrivileges=true
>  > PrivateDevices=true
>  > PrivateTmp=true
>  > ProtectHome=true
>  > ProtectControlGroups=true
>  > ProtectKernelModules=true
>  > ProtectKernelTunables=true
>  > ProtectSystem=strict
>  > ReadWritePaths=/var/lib/nsd /etc/nsd /run
>  > RuntimeDirectory=nsd
>  > RestrictRealtime=true
>  > SystemCallArchitectures=native
>  > SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module mount 
> @obsolete @resources
> 
>  > [Install]
>  > WantedBy=multi-user.target
> 
> Once I remove following line,
> 
>  > CapabilityBoundingSet=CAP_CHOWN CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID 
> CAP_SETUID CAP_SYS_CHROOT
> 
> while it does not help to only remove params from it (I need to remove the full 
> line), the error message changes to:

To override a setting you need to reset it and then set it to what you
want, otherwise similar directives accumulate. Like this:

CapabilityBoundingSet=
CapabilityBoundingSet=MY_NEW_SET_OF_CAPS

>  > Nov 24 16:37:57 ns2 systemd[1]: Starting Name Server Daemon...
>  > Nov 24 16:37:57 ns2 nsd[1607]: [2019-11-24 16:37:57.144] nsd[1607]: error: 
> Cannot open /var/log/nsd.log for appending (Read-only file system), logging to 
> stderr

With the IMO good ProtectSystem=strict, nsd can only ever write to
directories listed in ReadWritePaths=.

>  > Nov 24 16:37:57 ns2 nsd[1607]: [2019-11-24 16:37:57.145] nsd[1607]: notice: 
> nsd starting (NSD 4.1.26)
>  > Nov 24 16:37:57 ns2 nsd[1607]: [2019-11-24 16:37:57.252] nsd[1608]: notice: 
> nsd started (NSD 4.1.26), pid 1607
>  > Nov 24 16:37:57 ns2 systemd[1]: Started Name Server Daemon.
> 
> Since nsd-control zonestatus now works, NSD now can read 
> the /var/lib/nsd/zone.list.

It's a wild guess but maybe /var/lib/nsd/zone.list is opened by nsd
while still running as root. When you have reduced caps
(CapabilityBoundingSet), you don't have CAP_FOWNER, CAP_DAC_READ_SEARCH
and/or CAP_DAC_OVERRIDE so might get a permission error.

I'm not sure if the right thing to do would be to have nsd open the file
post SETUID/GID or if more caps should be added.

> However, it is still not running fine because now 
> NSD says it cannot open the /var/log/nsd.log.
> 
> Does anyone know how to fix that?

If you want nsd to do logging to a file directly, you'll need to add it
to the ReadWritePaths. I'd suggest "sudo systemctl edit nsd" then enter
and save the following:

  [Service]
  ReadWritePaths=/var/log

Then "sudo systemctl restart nsd". You can also throw in the
CapabilityBoundingSet tweaks you want in there.

HTH,
Simon
_______________________________________________
nsd-users mailing list
nsd-users@NLnetLabs.nl
https://open.nlnetlabs.nl/mailman/listinfo/nsd-users
_______________________________________________
nsd-users mailing list
nsd-users@NLnetLabs.nl
https://open.nlnetlabs.nl/mailman/listinfo/nsd-users

Reply via email to