nsd users - Nov 2011 - nsd[6775]: failed to unlink pidfile /var/run/nsd/nsd.pid: Permission denied

nsd[6775]: failed to unlink pidfile /var/run/nsd/nsd.pid: Permission denied


I think this is an old bug?

The daemon creates the pid as root, and "nsdc restart" has no root
permission
to replace the pid file.

As a workaround, I will create the /var/run/nsd dir with group nsd, and change
the initscript to use:

[ -d $NSD_PIDDIR ] || mkdir -p $NSD_PIDDIR && chown nsd $NSD_PIDDIR

But this is really an nsd bug to fix.

Paul

At Tue, 29 Nov 2011 14:01:00 -0500 (EST), Paul Wouters <paul at
xelerance.com> wrote:
Subject: [nsd-users] nsd[6775]: failed to unlink pidfile /var/run/nsd/nsd.pid:
Permission denied
> 
> 
> nsd[6775]: failed to unlink pidfile /var/run/nsd/nsd.pid: Permission denied
> 
> 
> I think this is an old bug?
> 
> The daemon creates the pid as root, and "nsdc restart" has no
root permission
> to replace the pid file.
> 
> As a workaround, I will create the /var/run/nsd dir with group nsd, and
change
> the initscript to use:
Making the PID file, or any path to it, writable by the unprivileged
user whom the daemon normally runs as is just plain wrong, at least on
some systems.

I.e. on systems where the root user trusts the contents of the PID file
to be a reference to the process identified by the pathname of said PID
file, by allowing the unprivileged daemon user to modify that file in
any way will give a potential attacker a vector which will allow that
attacker to inflict actions (e.g. SIGHUP, SIGTERM, etc.) by the
superuser on arbitrary other processes.

Therefore the unprivileged daemon should not ever attempt to remove its
own PID file.

I thought we'd been through all this before on this very list?

(arguably the creation of the PID file or something similr should be
done by a privileged "wrapper" program which starts the daemon and
perhaps monitors it, but that's not how these types of programs are
typically implemented today, and perhaps such a wrapper should even be
supplied by the system and not the daemon author -- e.g. one could
consider Darwin's launchd(8) to be such a wrapper program, but it is not
universally available, yet, and I don't think it yet offers the ability
to give a daemon access to privileged resources, such as handing it an
open socket on a privileged port via a specified file descriptor, for
example, but it could, and arguably should be able to do this.)

-- 
						Greg A. Woods
						Planix, Inc.

<woods at planix.com>       +1 250 762-7675        http://www.planix.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL:
<http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20111202/258b833f/attachment.bin>