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
Processing control commands:
> forwarded -1 https://github.com/systemd/systemd/issues/8085
Bug #889144 [systemd] stricter PIDfile handling breaks several daemons
Set Bug forwarded-to-address to
'https://github.com/systemd/systemd/issues/8085'.
--
889144: https://bugs.debian.org/cgi-bin/bugrepor
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
Processing control commands:
> severity -1 serious
Bug #889144 [systemd] stricter PIDfile handling breaks several daemons
Severity set to 'serious' from 'important'
--
889144: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889144
Debian Bug Tracking System
Contact ow...@bugs.debian.org with p
13 matches
Mail list logo
