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... > 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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
