I ran into this issue too. I think that, in principle, daemons should
not be able to write to their own configuration files, so making the
files owned by root is a good thing anyway. The only real trouble is
that things break on upgrade due to the earlier default ownership.
One other related
Confirmed, on every system upgraded to buster, nsd fails to start (even
with a blank configuration file i.e. all settings at defaults):
systemd[1]: Starting Name Server Daemon...
nsd[10191]: error: could not open zone list /var/lib/nsd/zone.list:
Permission denied
nsd[10191]: error: could not
Thank you very much! Adding CAP_DAC_OVERRIDE solved it for me as well. Not sure
how many hours it would have taken for me to figure it out.
Does systemd or the linux kernel log capability violations somewhere? (is it
even possible)
smime.p7s
Description: S/MIME Cryptographic Signature
To be clean, I'm all for the systemd hardening. I'm just reporting a
case where the current configuration appears to have a gap. I'm in
agreement that the DAC_OVERRIDE may be too big of a hammer, but I wasn't
able to quickly identify another alternative without switching to the
Hi Joel,
thanks for the report.
The systemd service file has been in part of the package for 5 years,
with the default ordering of sections (unit, service, install).
The upstream service while was more less recently added (~1 year ago).
Since systemd hardening has been available and
Package: nsd
Version: 4.1.26-1
Severity: important
--- i/debian/nsd.service
+++ w/debian/nsd.service
@@ -8,7 +8,7 @@ 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
6 matches
Mail list logo
