Re: Running pam-enabled /bin/login sessions in unprivileged terminal emulators

[nerdopolis <bluescreen_avenger@xxxxxxxxxxx>]

On Saturday, May 22, 2021 3:14:27 PM EDT Pekka Paalanen wrote:
> On Sat, 22 May 2021 09:04:42 -0400
> nerdopolis <bluescreen_avenger@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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.
> 

Sounds like you would need to make VTE start up with nothing running, and have
VTE report the PTY that it got?
> 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.
> 

Seems like I would need to elevate to have an unprivileged parameterized
service start a dependant with a _different_ parameter? 

With this, it seems you would have frontend@.service
where frontend@.service replaces autovt@.service
(frontend@.service runs as the system user)

If I have it dependant on backend@.service, it automatically starts it with the
same parameter. (from there I just use a socket with the parameter name)

Not sure how frontend@tty1.service would start backend@/dev/pts/0.service ?
And if you start backend first, it's going to need to know the pty still...
> 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.
> 

Wait, do normal TTYs do locking? CTRL+ALT+FX or chvt, and I've never seen a
lock on them...
> > 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. :-)
> 
> 

Sorry, one hint, Ignore the SIG_WINCH stuff and ptycommandproxy. That's a
separate FIFO for allowing the unprivileged account for using stty to set 
the size of the server pty to be the same as the frontend pty so text mode
applications like nmtui and text editors work correctly...

Those do make the script more complex
> 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.
> 




_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel