[systemd-devel] [HACK/RFC/PATCH] systemd-su: "su" on steroids

[Lennart Poettering]

On Mon, 02.12.13 21:47, David Herrmann (dh.herrmann at gmail.com) wrote:

> 
> 4h later, I present "systemd-su":
> 
> If you want to give it a try, run:
>   systemd-su -u david /bin/sh
> 
> It requires the systemd-suexec helper internally, so if you didn't install
> it, use something like this:
>   SYSTEMD_SUEXEC=/home/david/dev/systemd/systemd-suexec ./systemd-su -u david sh
> Otherwise, systemd-su cannot find the systemd-suexec binary.

Hmm, if we allow that "su -" tells logind to create an entirely new
session even when called from an existing one, do we still need
"systemd-su"? That should be pretty close, no? That sounds easier to
do...

> Additionally, I create an anonymous AF_UNIX socket in systemd-su which
> systemd-suexec connects to. I then pass file-descriptors to systemd-suexec
> which installes them as STDIN/OUT/ERR.
> I actually think it would be quite useful to extend the
> StartTransientUnit() dbus call to allow passing FDs. It would allow us to
> "store" FDs with active units, which would be useful for a lot of other
> concepts (like storing DRM framebuffer handles..).

Hmm, so we thought about adding support for something like a per-service
fd storage facility in systemd. This would be populated from the .socket
units, but could also be passed in for transient units by the caller or
even updated by the services themselves if they want to store additional
fds in systemd. This would solve a number of issues for us, including
one big one: currently if you restart systemd-journald you lose the
per-service stdout/stderr connections because there's no way to save
them.

Lennart

-- 
Lennart Poettering, Red Hat