On Wed, 11.12.13 15:57, David Herrmann (dh.herrm...@gmail.com) wrote:
>
> Hey
>
> On Wed, Dec 11, 2013 at 3:27 PM, Lennart Poettering
> <lenn...@poettering.net> wrote:
> > On Wed, 11.12.13 13:54, David Herrmann (dh.herrm...@gmail.com) wrote:
> >
> >>
> >> 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.
> >
> > The new switch I was suggesting for pam_systemd ("force-new-session=1")
> > would cause a new session to be started from within an existing one, in
> > that case decoupling the session id from the audit id. Hence, when you
> > first log into a computer you will get a session with a session ID
> > identical to the audit id. However if you use "su -" which then does
> > force-new-session=1 on pam_system you will get a new session that gets
> > an independent id, that is decoupled from the audi session, and to avoid
> > namespace clashes is prefixed with a lower-case "c". We'd only do that
> > for "su -"/"sudo -i", not for "su", "su -".
>
> Yeah, I understand that and our code already does that, except for
> CreateSession() which always tries to pick up existing sessions. My
> question rather is: why would anyone want "su --login" to start a new
> session? Yeah, it's needed to set env-variables correctly on
> uid-change or set other things. But I've never seen a use-case where
> someone really wants a new session. Imho, su/sudo is exclusively used
> to change euids.
Well, people do find it useful to quickly change identities. I use it
like that all the time too actually. It's a bit like ssh'ing to the
localhost, except that it doesn't require IP. And I am pretty sure that
we should support it like that. For example, I make use of it all the
time in containers, where nspawn just gives me a single console where I
scan log in once. If I quickly need to change identity, then "su -" and
"sudo -l" are certainly quicker then to open another window and use "ss"
or "machinectl login" to get a second login....
> > "su -" and "sudo -i" would hence do the "greatest possible"
> > disconnection from the originating session. (switch everything possible
> > except the tty itself)
>
> There is actually one thing, that you *cannot* share between
> legacy/unix sessions, which is the CTTY. Only one SID can be assigned
> a given TTY as CTTY. We can avoid the setsid() call, obviously, but
> that seriously questions the idea why a new session is needed. Again,
> if you want to share the CTTY (which su/sudo usually do), it seems
> weird to not share the session.
Well, but su/sudo give up the ctty while the transition is being done,
and takes it back afterwards...
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
