nsd icon indicating copy to clipboard operation
nsd copied to clipboard

Ubuntu Focal Fossa pidfile and logfile permission denied issue

Open maintain3r opened this issue 4 years ago • 11 comments

Hello people, Im facing an issue related to nsd PID and logfile access. Here's a piece of my logfile: [2020-09-08 14:11:12.813] nsd[48310]: error: cannot open pidfile /run/nsd/nsd.pid: Permission denied [2020-09-08 14:11:12.813] nsd[48310]: error: cannot overwrite the pidfile /run/nsd/nsd.pid: Permission denied

I tried to modify my systemd unit and made it less restrictive so it can access the files it needs. I even tried to chmod 0777 the files it complains about but still no success. Is there a fix for that or I do smth worng? Please advise/help! p.s. same thing happens with unbound

maintain3r avatar Sep 08 '20 14:09 maintain3r

Are the folders in the path accessible? Also to the username that nsd or unbound runs as? I mean the chmod of the directories, like /run/nsd.

wcawijngaards avatar Sep 08 '20 14:09 wcawijngaards

Thank you @wcawijngaards for a quick reaction to this. Here's yet another portion of info (sorry it's long) image

maintain3r avatar Sep 08 '20 14:09 maintain3r

The nsd version above is just the source tree that I've downloaded few minutes ago. The actual version is the one that comes by default with Ubuntu server 20.04.1 root@ubuntu-20-04-01:~# nsd -v NSD version 4.1.26 Written by NLnet Labs.

Copyright (C) 2001-2006 NLnet Labs. This is free software. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

maintain3r avatar Sep 08 '20 14:09 maintain3r

You omitted the ls -ld /run/nsd , the permissions on that directory also have to allow NSD to access it.

In reality this bug, if you installed the debian package, is in the debian package file. There are different ways to set up the sysadmin around the NSD daemon. Or at least, that seems likely, there does not seem to be something wrong with what the NSD source code is doing, but something seems to be wrong with the set up of the file system.

wcawijngaards avatar Sep 09 '20 07:09 wcawijngaards

But, now I see that under the usename NSD you can ls the file owned by user nsd of nsd.pid. So it should work, but it does not. Perhaps the systemd permissions in the config file for the systemd service for nsd is wrong, and it restricts access, not allowing the /run/nsd directory in the permissions. But I do not know what the contents of the file is, because we do not do the packaging, really, but I guess that is where it could be. The /lib/systemd/system/nsd.service file that systemd talks about, likely?

wcawijngaards avatar Sep 09 '20 07:09 wcawijngaards

Thank you @wcawijngaards for your time. /run/nsd dir belongs to nsd user and it's able to read/write to that dir. Here's the content of the systemd nsd unit file (comes with the deb pkg, I just added /var/log dir in ReadWritePaths). image As you can see, /run dir is also part of the ReadWritePaths setting, and looks like everything should work, but it doesn't. Also, if I change logfile and pidfile to another locations, /tmp for instance - it doesn;t work. If I put '0777' for the entire /run dir - it doesn;t work either. image image nsd.conf image

maintain3r avatar Sep 09 '20 14:09 maintain3r

Yeah I do not see the problem either. There was a bunch of discussion about systemd files and after that we removed out contrib/nsd.service example for systemd configuration.

Another thing is that your config does not disable chroot, with chroot: "", and that would modify all the paths, because the chroot location would be used as a prefix for all those paths. But then I would not expect a Permission Denied error, but something about the path does not exist.

wcawijngaards avatar Sep 09 '20 14:09 wcawijngaards

Setting chroot: "" doesn't change the picture ( I didn't set it explicitly, expecting it's disabled by default (correct me if Im wrong)

maintain3r avatar Sep 09 '20 15:09 maintain3r

Here's the new systemd nsd unit: [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

[Install] WantedBy=multi-user.target

$ cat nsd.conf server: logfile: /tmp/nsd.log pidfile: /run/nsd/nsd.pid chroot: ""

$ systemctl restart nsd $ cat /tmp/nsd.log [2020-09-09 11:11:27.686] nsd[108227]: notice: nsd starting (NSD 4.1.26) [2020-09-09 11:11:27.757] nsd[108240]: notice: nsd started (NSD 4.1.26), pid 108227 [2020-09-09 11:11:45.802] nsd[108240]: warning: signal received, shutting down... [2020-09-09 11:11:45.803] nsd[108240]: warning: failed to unlink pidfile /run/nsd/nsd.pid: Permission denied

maintain3r avatar Sep 09 '20 15:09 maintain3r

So it works to create the pidfile, that does not have an error now. It only prints an error on exit, that you could ignore; removal of the old pidfile is not essential. Also, chroot is likely enabled by default. So after the chroot it cannot unlink the pidfile any more, instead of having a file-not-found error, it prints permission denied. Perhaps something that happens inside the chroot directory, permissions of the files and directories inside it.

wcawijngaards avatar Sep 10 '20 06:09 wcawijngaards

As nsd is a universe package, the package comes straight from Debian. As the maintainer there, the problem with the PIDfile was resolved by just not using it anymore as systemd does not need it to track nsd. So we have there: ExecStart=/usr/sbin/nsd -d -P ""

asciiprod avatar Feb 08 '21 10:02 asciiprod