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. > 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 _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel