Hi On Wed, Dec 11, 2013 at 12:18 AM, Lennart Poettering <lenn...@poettering.net> wrote: > On Mon, 02.12.13 21:47, David Herrmann (dh.herrm...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel