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

[David Herrmann]

Hi

On Wed, Dec 11, 2013 at 12:18 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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...

You cannot start a session from within an existing session. At least
if audit-loginids are immutable, this also means the audit-sessionid
is immutable (as the session ID is updated if, and only if, the
logind-uid changes).

Of course, immutable audit IDs are a somewhat controversial feature
(and afaik don't work with containers?) but I still dislike the idea
of starting sessions from within an existing session. It's ugly and we
don't actually need it, do we? Currently su/sudo don't start new
sessions and I think that is fine. Imho, their intention is to change
the EUID, not to spawn a new session.

So my hack here is just some example to play with, not something for
real to replace su/sudo.

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

Yepp! I think we talked about it 2 years ago at LPC. Would be a pretty
useful feature.. If I find time for it, I will give it a try.

Thanks
David