You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is problematic, though. From start-stop-daemon's man page:
-p, --pidfile pid-file
Check whether a process has created the file pid-file.
Note: using this matching option alone might cause unintended
processes to be acted on, if the old process terminated without
being able to remove the pid-file.
Warning: using this match option with a world-writable pidfile
or using it alone with a daemon that writes the pidfile as an
unprivileged (non-root) user will be refused with an error
(since version 1.19.3) as this is a security risk, because
either any user can write to it, or if the daemon gets
compromised, the contents of the pidfile cannot be trusted, and
then a privileged runner (such as an init script executed as
root) would end up acting on any system process. Using
/dev/null is exempt from these checks.
And sure enough, the shipped init script doesn't actually stop the daemon,
and restarts don't populate the pid file but do leave multiple daemons
running.
It's unclear to me why the pidfile would ever want to be chown'd. I see in
the changelogs:
26 January 2016: Wouter
- Fix #734: chown the pidfile if it resides inside the chroot.
...but I'm not sure where that buglist is to gather context. Seems like a
pidfile should explicitly not be inside a chroot under most circumstances,
unless the daemon is trying to relaunch itself chrooted...?
Either not chowning at all or having a runtime knob to control this
chowning would be useful fixes. Thoughts?