[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170911202142.rnfiesjl7mjho4pg@perpetual.pseudorandom.co.uk>
Date: Mon, 11 Sep 2017 21:21:42 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2017-12847: nagios-core privilege escalation
via PID file manipulation
On Mon, 11 Sep 2017 at 15:58:45 -0400, Michael Orlitzky wrote:
> With OpenRC
> we get to cheat a little, because we always have the option to run the
> daemon in the foreground and supervise it.
For SysV, if you don't need readiness-notification (for daemons that
other daemons don't depend on, so the ones where Type=simple would be
acceptable in a systemd unit) then Debian's start-stop-daemon can provide
the daemonization, and create a pid file if desired. This isn't proper
supervision, but does give the ability to write the daemon as though it
relied on being supervised.
start-stop-daemon is shipped as part of dpkg for historical reasons, but
I doubt it changes very often. If SysV init script writers wanted to spin
it off into a separate upstream project, then it could perhaps eventually
become non-Essential in Debian (since it isn't necessary if a machine boots
with systemd and all the daemons on that machine have native systemd units),
and that seems like a potential win for everyone?
(Also, one of the most vocally SysV-based distributions is a
Debian derivative, so they have start-stop-daemon anyway.)
S
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
