Greeter summary issue

[williamleven]

Situation

We currently use greetd with the gtkgreet graphical frontend.

Issues

This setup has several problems:

1. No ability to set a default user, have to type in username each time.
2. Broken keyboard navigation as the login button is not focusable on fingerprint prompts.
3. You need to click "login" after scanning your fingerprint to know if the scan was accepted.

Tried solution

Our initial impression was that these issues were caused by gtkgreet and to remedy these issues we attempted to to implement our own frontend for greetd. This easily solves issues 1 & 2, but it turns out issue 3 is due to an API design flaw in greetd.

Learned along the way

1. Although it is not stated, the greetd ICP protocol is unary. Meaning that every response message must be preceded by a request from the frontend.
2. PAM protocol is also unary but requests are initiated from PAM.
3. greetd frontends need a precise set of permissions to run. see install script:

   sudo cp --force ./go-greet /usr/local/bin/
   sudo chmod 751 /usr/local/bin/go-greet
   sudo chown root:root /usr/local/bin/go-greet
   sudo restorecon -Fv /usr/local/bin/go-greet

Architechtural problems with greetd

As noted above the only way to get information from greetd to the greeter frontend is to submit a request (mapped to an action). This works great for situations where the next step in the login process is accomplished by the user submitting more information through the greeter frontend, such as username, or password flows. It is however not optimal for login steps where the flow proceeds through direct interaction with PAM such as fingerprint, keys, or timeouts as the greeter frontend has no opportunity to be notified of the state of these flows as they progress.

Way forward

We can either

1. Try to circumvent the limitations of greetd by polling some ICP request for state changes. Not entirely sure if this will work as it depends on the internals of greetd.
2. Propose changes to and/or fix the flaws in greetd.
3. Use another of the shelf greeter with wayland support, see: https://wiki.archlinux.org/title/Display_manager
4. Implement our own greeter, example: https://github.com/tvrzna/emptty/

[HerrNaN]

I like ideas 2 and 3, although I think our best way forward for now is 3 (finding an off-the-shelf solution).

My suggestion is to start experimenting with GDM.

[HerrNaN]

We have since a while back moved to GDM. Let's reopen this when/if we move back to greetd