Bug#889144: stricter PIDfile handling breaks several daemons

On 04/02/18 20:26, Sven Hartge wrote: > Does dnsmasq need a PIDfile when running under systemd? Can't it just > not double fork, stay in the foreground using a Type=simple systemd unit? > > That way the whole problem could be avoided all together. > Sending signals to the dnsmasq process cause

Bug#889144: stricter PIDfile handling breaks several daemons

Am 04.02.2018 um 21:26 schrieb Sven Hartge: > On Sun, 4 Feb 2018 15:41:37 + Simon Kelley > wrote: > >> With my dnsmasq maintainer hat on, the current arrangement looks like this. >> >> 1) /run/dnsmasq is a directory owned by dnsmasq:nogroup >> 2)

Bug#889144: stricter PIDfile handling breaks several daemons

On Sun, 4 Feb 2018 15:41:37 + Simon Kelley wrote: > With my dnsmasq maintainer hat on, the current arrangement looks like this. > > 1) /run/dnsmasq is a directory owned by dnsmasq:nogroup > 2) /run/dnsmasq/dnsmasq.pid gets written by dnsmasq before it drops > root,

Bug#889144: stricter PIDfile handling breaks several daemons

On 04.02.2018 17:25, Michael Biebl wrote: > Am 03.02.2018 um 14:35 schrieb Sven Hartge: >> Um 14:00 Uhr am 03.02.18 schrieb Michael Biebl: >>> The alternative afaics would be, that the daemon writes the pid file as >>> munin:munin then (or ulog:ulog for the above case). >> >> No, this would open

Bug#889144: stricter PIDfile handling breaks several daemons

Am 03.02.2018 um 14:35 schrieb Sven Hartge: > Um 14:00 Uhr am 03.02.18 schrieb Michael Biebl: >> The alternative afaics would be, that the daemon writes the pid file as >> munin:munin then (or ulog:ulog for the above case). > > No, this would open a potential DoS vector. > > Image an attacker

Bug#889144: stricter PIDfile handling breaks several daemons

With my dnsmasq maintainer hat on, the current arrangement looks like this. 1) /run/dnsmasq is a directory owned by dnsmasq:nogroup 2) /run/dnsmasq/dnsmasq.pid gets written by dnsmasq before it drops root, so is root:root 3) The reason /run/dnsmasq is owned by dnsmasq is so that dnsmasq can

Bug#889144: stricter PIDfile handling breaks several daemons

Control: forwarded -1 https://github.com/systemd/systemd/issues/8085 Hi Sven, I filed an upstream issue at https://github.com/systemd/systemd/issues/8085 trying to summarize what the issue is afaiu from reading this and related bug reports. If you have further feedback or corrections, please

Bug#889144: stricter PIDfile handling breaks several daemons

Um 14:00 Uhr am 03.02.18 schrieb Michael Biebl: > Am 03.02.2018 um 13:27 schrieb Sven Hartge: >> Um 03:02 Uhr am 03.02.18 schrieb Michael Biebl: >>> Does munin-node have the same mismatch? >> It has: >> But, as you can see, the directory is also used by the munin-updater >> which is run as

Bug#889144: stricter PIDfile handling breaks several daemons

Am 03.02.2018 um 13:27 schrieb Sven Hartge: > Um 03:02 Uhr am 03.02.18 schrieb Michael Biebl: > >> Am 02.02.2018 um 20:07 schrieb Sven Hartge: > >>> ulogd2 drops its priviliges on its own. It needs to start as root to >>> connect to the netlink sockets. > >> So, ulogd2 creates a directory

Bug#889144: stricter PIDfile handling breaks several daemons

Um 03:02 Uhr am 03.02.18 schrieb Michael Biebl: > Am 02.02.2018 um 20:07 schrieb Sven Hartge: >> ulogd2 drops its priviliges on its own. It needs to start as root to >> connect to the netlink sockets. > So, ulogd2 creates a directory /run/ulog which is owned by ulog:ulog but > then creates the

Bug#889144: stricter PIDfile handling breaks several daemons

Am 02.02.2018 um 20:07 schrieb Sven Hartge: > ulogd2 drops its priviliges on its own. It needs to start as root to > connect to the netlink sockets. So, ulogd2 creates a directory /run/ulog which is owned by ulog:ulog but then creates the pid file /run/ulog/ulog.pid owned by root:root. I assume

Bug#889144: stricter PIDfile handling breaks several daemons

Control: severity -1 serious Am 02.02.2018 um 20:07 schrieb Sven Hartge: > On 02.02.2018 19:24, Michael Biebl wrote: >> Am 02.02.2018 um 14:58 schrieb Sven Hartge: > >>> The upstream commit db256aab13d8a89d583ecd2bacf0aca87c66effc "core: be >>> stricter when handling PID files and MAINPID

Bug#889144: stricter PIDfile handling breaks several daemons

On 02.02.2018 19:24, Michael Biebl wrote: > Am 02.02.2018 um 14:58 schrieb Sven Hartge: >> The upstream commit db256aab13d8a89d583ecd2bacf0aca87c66effc "core: be >> stricter when handling PID files and MAINPID sd_notify() messages" >> breaks several daemons in Debian. >> >> Known issues exist

Bug#889144: stricter PIDfile handling breaks several daemons

Am 02.02.2018 um 14:58 schrieb Sven Hartge: > Package: systemd > Version: 237-1 > Severity: important > Tags: upstream > > Hi! > > The upstream commit db256aab13d8a89d583ecd2bacf0aca87c66effc "core: be > stricter when handling PID files and MAINPID sd_notify() messages" > breaks several daemons

Bug#889144: stricter PIDfile handling breaks several daemons

Package: systemd Version: 237-1 Severity: important Tags: upstream Hi! The upstream commit db256aab13d8a89d583ecd2bacf0aca87c66effc "core: be stricter when handling PID files and MAINPID sd_notify() messages" breaks several daemons in Debian. Known issues exist for - munin-node