On Thu, 27 May 2021 17:33:35 +0200 Lennart Poettering <[email protected]> wrote:
> 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. Yes, sorry. I'm not clear what any of them actually do. Hence, please replace everything I've called "the login program" or similar with yours above. Thanks, pq > 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
pgpvov3lCxPQY.pgp
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
