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.
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.
Am I guessing right?
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'.
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.
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
Attachment:
pgpOp4WVgnGab.pgp
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
