On Sa, 22.05.21 13:50, Pekka Paalanen ([email protected]) wrote: > 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.
When you say /bin/login do actually intend to say "getty"? what is /bin/login good for here? it's a stub that expects you already give it a user and it then only asks for a pw. It's the second part of a getty pretty much. We have multiple services that you can instantiate on ttys, for example [email protected] (for true VTs), [email protected] (for serial ports), container-getty.service (for /dev/console), [email protected] (for gettys on pseudo TTYs, pretty much). It appears to me that the right approach for your case is to do what [email protected] effectively does and instantiate an appropriate instance of a template service modelled after it for the "other" side of the pty your terminal app allocates. Instantiating <yourapp>[email protected] requires privs, but you can use polkit to grant that to your terminal app's user. THe polkit auth request carries the unit name as additional metadata, hence that should be pretty easily done with some minimal polkit JS. Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
