On Tue, Nov 03, 2020 at 12:24:35PM +0900, Simon Walter wrote:

> > Could it be related to this?
> >
> > https://github.com/NLnetLabs/unbound/issues/303
>
> I don't think so - unless you are paranoid about anything that RH employees
> contribute to.

Hah, if you're paranoid about projects RH employees contribute to, then
you're all in trouble. :P

But yes. I'd found an issue where Unbound wasn't obeying service management
in Devuan, and then that spiraled out into it being CVE-worthy. But for our
purposes, unbound changes ownership if its PIDfile, and this means that our
start-stop-daemon refuses to operate on it - if the process can be
subverted, it can write any PID in there, for instance, and cause us to
kill an arbitrary daemon. If the process can make the PIDfile into a
symlink, it can maybe cause us to overwrite arbitrary files, and so forth.

It's not yet wholly clear how upstream will fix it. Depending on that, we
might end up needing to fork it - Debian will be unaffected since they
don't insist on sysvinit compatibility any more.

For my part, I've stopped using unbound at all. I've been using BIND for
many years, and it works just fine in this role too.

-- 
  Mason Loring Bliss         mason@???        http://blisses.org/  
For more enjoyment and greater efficiency, consumption is being standardized.