On Thu, 27 May 2021 17:33:35 +0200 Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote: > On Sa, 22.05.21 13:50, Pekka Paalanen (ppaalanen@xxxxxxxxx) 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 getty@.service (for true VTs), serial-getty@.service (for > serial ports), container-getty.service (for /dev/console), > container-getty@.service (for gettys on pseudo TTYs, pretty much). > > It appears to me that the right approach for your case is to do what > container-getty@.service 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>-getty@.service 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
Attachment:
pgpWzFHecxDJB.pgp
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
