Re: Running pam-enabled /bin/login sessions in unprivileged terminal emulators

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

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.

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