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
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) /run/dnsmasq/dnsmasq.pid gets written by dnsma
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, so is root:root
> 3) The r
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 a
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 ga
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
unlink
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 dir
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 user
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 /run/
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
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
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 sd_not
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 for
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
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 https://bugs.
15 matches
Mail list logo