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