[systemd-devel] Revisiting the "ExecRestart" issue

[Brandon Black]

On Thu, Apr 24, 2014 at 1:34 AM, Lennart Poettering
<lennart at poettering.net>wrote:

> On Wed, 23.04.14 21:20, Brandon Black (blblack at gmail.com) wrote:
>
> > The problem here is that the daemon performs operations that require root
> > privilege on startup, and then dumps its privileges for runtime, and thus
> > its execve'd child won't have the root privs it would need to start
> > everything over again.  In theory some of these privileged things, like
> > listening sockets, could be handed to the exec child, but that assumes
> the
> > configured set of listening sockets hasn't changed (which might be the
> > reason for the restart).
>
> There's always the option to raise the privs again via some setuid
> helper...


That would seem to defeat the purpose of losing them in the first place
(limiting the damage potential of a compromised daemon).


> > Other things like mlockall() can't be handed off
> > over fork/execve once privileges are gone.
>
> mlockall()? what's that supposed to do here? this is usually snakeoil...


This seems like another side-topic, but what about mlockall is snakeoil?
 Should that be documented somewhere? It was just the first example of a
privileged operation we use that came to mind.  It's an optional
(default-off) thing in gdnsd, but it seems like if you care about response
latency enough to minimize syscalls, minimizing pagefaults in the presence
of less-important batch processes that may consume significant memory is a
good idea as well.  In any case, no, I don't think I can completely get rid
of privileged ops on startup at this time.


> > officially letting a control process from ExecReload= become the main
> > process via some reasonably-standard mechanism?  That's already what
> > happens to the "control process" for ExecStart=.
>
> Well ExecStart= is very special, it's not the control process, really.


Semantics.  Can we not have some other verb be as special?  My point is,
the systemd code certainly knows how to do this, it just doesn't chose to
for ExecReload.  There could be an option declared for that behavior,
though, if it were a solution.


> > 2) Given the above, would it be reasonable that if a control process
> from a
> > verb like ExecReload sent a MAINPID= message over the control socket,
> > systemd would accept this as the new main pid *and* internally take care
> of
> > promoting the specified PID to the proper cgroup?
>
> Hmm, this becomes messy if the daemon actually is more than one
> process (think worker processes)... Not sure how we would handle that?


I assume you mean worker processes which detach themselves from the parent
via setsid() and thus don't show a relationship to it (why would the daemon
chose to disassociate worker children like that? I have no idea).
 Otherwise we could just move the whole process group of the sender of the
MAINPID= message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140504/fd4064b8/attachment.html>