[systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators

[nerdopolis]

On Saturday, May 22, 2021 6:50:09 AM EDT Pekka Paalanen wrote:
> On Fri, 21 May 2021 21:29:09 -0400
> nerdopolis <bluescreen_avenger at verizon.net> wrote:
> 
> > Sorry, I got the terminology mixed up again. I am still using TTYs to run the
> > instances of `cage`. It's the kernel mode VT emulators I am replacing with the
> > user mode terminal emulators (running under a fullscreen Wayland compositor)
> 
> Hi,
> 
> I'm trying to clarify things for everyone here, since I think I can
> guess what you want to achieve, but you have a hard time explaining
> your original goal. I hope you don't mind.
> 
> 
That's fine. Thanks!
> Starting from the outermost "layer" and going inwards:
> 
> 1.a Have a system service, that takes over VT 1, changes user to
>     'vtty', and runs 'cage' which is a Wayland compositor, mostly
>     unprivileged.
> 
> OR
> 
> 1.b Have a system service, that takes over a seat directly, as the
>     kernel has the VT system disabled (or the seat is not seat0).
>     Changes user to 'vtty' and runs 'cage' mostly unprivileged.
> 
> 
> 2. Inside cage, you run a Wayland terminal emulator as user 'vtty',
>    so mostly unprivileged. The terminal emulator creates a PTY.
> 
> 3. Inside that terminal emulator, that is, connecting to that PTY,
>    you want to be able log in with any user. Therefore the program
>    running on the PTY should present a login prompt and succeed
>    in logging a user in and setting up his session, and switching
>    to a shell running as that user.
> 
> All in all, this stack would replace the usual stack where
> /bin/login runs directly on the TTY of a VT, allowing to use a more
> featureful terminal, custom display modes, multi-output support,
> maybe multiple parallel sessions for different users a la fast user
> switching, and more.
> 

Not to mention, getting Shift+PgUp back, (and now on multiseat systems,
keyboard input from non-seat0 seats will no longer bleed into seat0 when VT 1-6
are active) :)
> Am I guessing right?

You are guessing correct. Thanks!
> 
> Then the question is, how to organize all this so that it works,
> and what program(s) should be used in step 3, and how?
> 
> 
> My own proposal for this would be to run everything as systemd
> system services:
> 
> 1. Cage runs as a system service, as user 'vtty'. Cage will require
>    systemd integration so that it can tell systemd when it is ready
>    to accept Wayland clients.
> 
> 2. The Wayland terminal runs as another systemd system service,
>    depending on the cage service, as user 'vtty'.
> 
That's close to what I was trying, but cage is pretty cool in this regard, you
can start
    cage -- vte
and cage starts VTE as its only client, so the complexity of starting the
wayland client externally, don't have to worry about that.
> 3. The login program runs as a third systemd system service,
>    depending on the terminal service, as user 'root' because it
>    needs to be able log in a user and set up a session for them.
> 
> That would solve the problem of how to get the necessary privileges
> to log in a user, but all the other details I'm not sure.
> 
That's what I was aiming to do, wasn't sure how to connect to the service until
I found I can do that with socat a few days after I sent that first email to 
the list, but I still feel I should still clarify here.

and if you're really curious, I have the .service files I made public
https://github.com/n3rdopolis/fakekmscon/tree/master/usr/lib/systemd/system
> So the main idea here is to not run /bin/login *under* the terminal
> emulator or cage, but as a system service which just connects to the
> right PTY. I guess it would be like running /bin/login for a serial
> terminal, it just connects to ttyS1 or whatever instead of tty1.
> 
> Would that work?
> 
> 
> Thanks,
> pq