nsd users - Apr 2020 - Permission error after upgrade to Debian Buster (10.2)

Actually with sudo chmod 666 /var/run/log/nsd.log works fine !

El s?b, 14-12-2019 a las 11:52 -0300, Jos? Luis Artuch
escribi?:
> Hi Anand,
> 
> El s?b, 14-12-2019 a las 10:15 +0100, Anand Buddhdev escribi?:
> > Hello guys,
> > 
> > I don't run Debian, so I can't offer a solution now, but I am
> > worried
> > that you're all just stumbling in the dark here, and randomly
> > changing
> > permissions on directories and files. A well-built package should
> > not
> > require any of this, and should just work. Has any one of you
> > approached
> > the maintainer of the Debian package? Perhaps it has been built
> > incorrectly, and needs to be fixed.
> > 
> > Regards,
> > Anand
> 
> No, at least I have not contacted the NSD package maintainer in
> Debian.
> Thank you so much for your advice.
> Regards.
> Jos? Luis
> 
> > On 13/12/2019 13:18, Kaulkwappe wrote:
> > > Unfortunately I still get this errors in NSD 4.1.26 on Debian
> > > Buster 10.2:
> > > 
> > > 1) Log file:
> > >  > error: Cannot open /var/log/nsd.log for appending
(Permission
> > > denied), 
> > > logging to std
> > > 
> > > When it se the owner of nsd.log to root:root, I don't get an
> > > error
> > > message on 
> > > start. However, after this start, NSD will change the owner to
> > > nsd:nsd and on 
> > > the next start I will get this error message.
> > > 
> > > 2) PID file:
> > >  > warning: failed to unlink pidfile /run/nsd/nsd.pid:
Permission
> > > denied
> > > It seems that NSD needs a PID file, because if I change pidfile: 
> > > "/run/nsd/nsd.pid" to pidfile: "" I get:
> > > 
> > >  > error: cannot open pidfile : No such file or directory
> > >  > error: cannot overwrite the pidfile : No such file or
> > > directory
> > > 
> > > 
> > > 
> > > -----------------------------------------------------------------
> > > ---------------
> > > *From:* Jos?Luis Artuch <zenbakaitz at speedy.com.ar 
> > > </email/new/1/zenbakaitz%40speedy.com.ar>>
> > > *Sent:* Tuesday, 26. Nov 2019 ? 01:03 CET +0100
> > > *To:* Kaulkwappe <kaulkwappe at prvy.eu
> > > </email/new/1/kaulkwappe%40prvy.eu>>
> > > nsd-users at NLnetLabs.nl
</email/new/1/nsd-users%40NLnetLabs.nl>
> > > 
> > > *Subject:* Re: [nsd-users] Permission error after upgrade to
> > > Debian
> > > Buster (10.2)
> > > 
> > > Hi Kaulkwappe,
> > > 
> > > El lun, 25-11-2019 a las 01:34 +0100, Kaulkwappe escribi?:
> > > > > [...] I'd double check if it's indeed effective
with
> > > > > "systemctl
> > > > show nsd | grep ReadWritePaths"
> > > > 
> > > > Seems to be effective:
> > > > > # systemctl show nsd | grep ReadWritePaths
> > > > > ReadWritePaths=/var/lib/nsd /var/log /etc/nsd /run
> > > > 
> > > > The problem with the log file will never stop the NSD
service
> > > > from
> > > > working (I believe) but the log file is quite important, so,
of
> > > > course, NSD should be able to append to it.
> > > > 
> > > > Does anyone already had this problem after an upgrade?
> > > > 
> > > > Kind Regards,
> > > > Kaulkwappe
> > > > 
> > > 
> > > My knowledge on this subject is very limited, but since you ask I
> > > give
> > > you my recent experience. I have also upgraded from Debian 9 to
> > > Debian
> > > 10, two ways, starting from Debian 9 and also from scratch. In
> > > both
> > > cases I have not got NSD to write the log file. I have tested
> > > changes
> > > of permissions and/or routes.
> > > However, I have not had problems with the start of NSD, but I
> > > clarify
> > > that I use NSD with a very elementary configuration and without
> > > /var/lib/nsd/zone.list defined.
> > > A cordial greeting.
> > > Jos? Luis
> > > 
> > > > From: Simon Deziel <simon at sdeziel.info>
> > > > Sent: Monday, 25. Nov 2019 ? 01:26 CET +0100
> > > > To: nsd-users at NLnetLabs.nl
> > > > 
> > > > Subject: Re: [nsd-users] Permission error after upgrade to
> > > > Debian
> > > > Buster (10.2)
> > > > 
> > > > On 2019-11-24 6:10 p.m., Kaulkwappe wrote:
> > > > > Hi Simon,
> > > > > 
> > > > >  > I would have expect a permission error instead of
a "read-
> > > > > only"
> > > > one. It
> > > > >  > looks as if /var/log was not properly added to be
> > > > > ReadWritePaths
> > > > set.
> > > > > That is what I have used:
> > > > >  > ReadWritePaths=/var/lib/nsd /var/log /etc/nsd
/run
> > > > 
> > > > Not sure what would explain the read-only error then.
I'd
> > > > double
> > > > check
> > > > if it's indeed effective with "systemctl show nsd |
grep
> > > > ReadWritePaths"
> > > > 
> > > > >  > This unlink failure is expected and AFAICT
harmless.
> > > > > It should be harmless, but it doesn't look nice. I
would
> > > > > consider
> > > > this as a bug.
> > > > 
> > > > Agreed. Interestingly, unbound accepts "-p" to
skip managing
> > > > its
> > > > own
> > > > PID. If nsd could get this, it would be handy when managing
the
> > > > daemon
> > > > with systemd.
> > > > 
> > > > >  > I believe that xfrd.state should be owned by
nsd:nsd as
> > > > > the
> > > > daemon needs
> > > > >  > to write to that file.
> > > > > After changing the owner to nsd:nsd I believe this
problem is
> > > > fixed. Thanks!
> > > > 
> > > > Glad to hear that!
> > > > 
> > > > Regards,
> > > > Simon
> > > > _______________________________________________
> > > > nsd-users mailing list
> > > > nsd-users at NLnetLabs.nl
> > > > https://open.nlnetlabs.nl/mailman/listinfo/nsd-users
> > > > _______________________________________________
> > > > nsd-users mailing list
> > > > nsd-users at NLnetLabs.nl
> > > > https://open.nlnetlabs.nl/mailman/listinfo/nsd-users
> > > 
> > > _______________________________________________
> > > nsd-users mailing list
> > > nsd-users at NLnetLabs.nl
> > > https://open.nlnetlabs.nl/mailman/listinfo/nsd-users
> > > 
> > _______________________________________________
> > nsd-users mailing list
> > nsd-users at NLnetLabs.nl
> > https://open.nlnetlabs.nl/mailman/listinfo/nsd-users

14.04.2020 16:51, Jos? Luis Artuch via nsd-users wrote:
> Actually with sudo chmod 666 /var/run/log/nsd.log works fine !
Gosh!
Well, chmod -R 1777 / will work too. But it is NOT, repeat: NOT
the way to go..

/mjt