[systemd-devel] [PATCH] core/service: check if mainpid matches only if it set

[Lennart Poettering]

On Fri, 14.02.14 02:51, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> > So, what I am afraid of here is that some process has some unpriviliged
> > children (CGI scripts or so), and for some reason they stay around after
> > the daemon itself is already terminated, and then can confuse
> > things... I mean, let's say somebody sets KillMode=none, and thus
> > processes can survive all the way into the next process start, and can
> > then quickly confuse systemd that they are the real main pid or so (for
> > example, by sending MAINPID= or so...). Or even if we consider the
> > KillMode=none thing irrelevant, then there might still be a small window
> > where the main pid is already dead and we kill the other processes and
> > wait for them and they then send us invalid data?
>
> In the bug report it seems that this happens during startup...
> Other cases where I saw this were also during startup, and KillMode
> was default, as far as I remember. Even if $MAINPID has died, we should
> be able to distinguish this from the case where it hasn't been set yet.

I am tempted to say that people either should use NotifyAccess=all in
this case, and thus clarify that they have no unprivileged rogue
processes around. Or, if that's not possible they have to use
Type=simple, where the problem would go away. Or if that's not possible,
then deal with dropped messages.

I mean, this feels a bit like trying to use the new apis but also the
old forking mess, at the same time. A bit like eating a cake, and having
it too. Or am I missing something?

Lennart

-- 
Lennart Poettering, Red Hat