[systemd-devel] Revisiting the "ExecRestart" issue

[Lennart Poettering]

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...

> 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...

> > Control processes really can't become the main process I
> > fear...
> 
> 
> They can; I've already done it by writing to /sys as documented above, but
> that doesn't seem like a reliable API for doing so going forward on all
> platforms and in all situations.  What's the fundamental problem with

Also note that sooner or later cgroupfs write access will be removed
from userspace applications...

> 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.

> I'd propose two changes (and work on the patches myself) that would make
> this case work for me reliably, if they're acceptable:
> 
> 1) Can we get $NOTIFY_SOCKET set for control procs like ExecReload
> when NotifyAccess=all ?  That's what I initially thought that setting would
> do, but apparently it doesn't.  Or any other standard mechanism I could
> rely on so that I'm not hardcoding a fallback socket path.

Hmm, we don't do this yet? This sounds like a useful thing to do. Added
to the TODO list for now...

> 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?

Lennart

-- 
Lennart Poettering, Red Hat