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. 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.
Attachment:
pgpK8P2WSmm1K.pgp
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
