Hi

With the apparmor profile shipped with unbound, /usr/sbin/unbound is
allowed to truncate and create its own pidfile /run/unbound.pid, but
cannot remove it at exit or rewrite it when it starts again.

As a consequence, "start-stop-daemon --stop" leaves behind an empty pidfile,
and a subsequent "start-stop-daemon --start" spawns a new daemon whose
pid is written nowhere.  The overall result is that N invocations of
"/etc/init.d/unbound restart" end up with N-1 daemons running, with
obvious implications for security.

In #947771 Stephane Lapie and Gedalya suggested a simple patch that
solves the problem.  That bug report was closed as "problem solved",
without actually applying the patch, probably because I failed to clearly
explain how to reproduce the issue.

Please, do not close this report unless, on a system managed by
sysvinit-core with apparmor in enforcing mode, exactly one instance of
unbound is left running after invoking "/etc/init.d/unbound restart"
at least four times in a row.

Since 2020, I've been applying the following patch against the script
shipped by the debian package at each new release, again and again.
Hope it can be included for real in the debian tree.

Best regards,
	g.
--- /etc/init.d/unbound.dpkg-dist	2021-02-09 23:53:57.000000000 +0100
+++ /etc/init.d/unbound	2022-11-19 08:28:58.429007869 +0100
@@ -42,7 +42,7 @@

     stop)
         log_daemon_msg "Stopping $DESC" "$NAME"
-        if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE --name $NAME --retry 5; then
+        if start-stop-daemon --stop --quiet --oknodo --remove-pidfile --pidfile $PIDFILE --name $NAME --retry 5; then
             $HELPER resolvconf_stop
             $HELPER chroot_teardown
             log_end_msg 0
@@ -53,7 +53,7 @@

     restart|force-reload)
         log_daemon_msg "Restarting $DESC" "$NAME"
-        start-stop-daemon --stop --quiet --pidfile $PIDFILE --name $NAME --retry 5
+        start-stop-daemon --stop --quiet --remove-pidfile --pidfile $PIDFILE --name $NAME --retry 5
         $HELPER resolvconf_stop
         if start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE --name $NAME --startas $DAEMON -- $DAEMON_OPTS; then
             $HELPER chroot_setup

Control: tag -1 + wontfix

This is interesting, since I closed that bug report after merging the
change mentioned in there, which is exactly what you propose below,
with --remove-pidfile option:

https://salsa.debian.org/dns-team/unbound/-/commit/baca147f4cd27753ceca3a2855f463ed905b7eeb

Ok, I'll left this bug open and tag it 'wontfix' for now, so it don't
catch my eyes from now on.

Thanks,

/mjt

30.08.2023 13:00, Michael Tokarev wrote:
...

Also removing the tag "patch" since the proposed patch is already applied,
it's impossible to apply it second time.

/mjt