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

Sat May 22 19:14:27 UTC 2021

On Sat, 22 May 2021 09:04:42 -0400
nerdopolis <bluescreen_avenger at verizon.net> wrote:

> 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.

But if cage starts the terminal, then systemd does not know when
the terminal is ready to accept a login program, or is there a way
to watch PTYs?

Ideally the terminal too would integrate with systemd start-up
notification IPC. Perhaps let systemd control which PTY to use, so
the login program/service knows to connect to the right one.

There's also auto-respawn, shutdown, cgroups, and more that systemd
can do.

> > 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.

The socat thing for "connection" sounds quite wild to me. Instead,
I would expect to start a login program with the PTY as its std
in/out/err, just like it works with normal VT TTY logins.

But then you do need to know which PTY it is. I think it would be
best to configure that as the parameter for templatated systemd
units: the terminal unit gets the PTY to listen on, and the login
unit gets the PTY to use as its controlling terminal and std
in/out/err. And the dependency between the two.

One problem here is how are you going to lock a terminal when
switching to another with a different user logged in. So maybe this
whole model is flawed, and you need authentication to work through
the Wayland compositor which is in charge of which terminal is
active.

> 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

I looked at the service files, and they don't seem to have much. I
looked at your libexec scripts, and they are much more complicated
than I expected, doing a lot more than I'm willing to try to
understand at this hour. :-)

Thanks,
pq

> > 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20210522/51931c57/attachment.sig>