We currently use greetd with the gtkgreet graphical frontend.
Issues
This setup has several problems:
No ability to set a default user, have to type in username each time.
Broken keyboard navigation as the login button is not focusable on fingerprint prompts.
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
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.
PAM protocol is also unary but requests are initiated from PAM.
greetd frontends need a precise set of permissions to run. see install script:
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
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.
Propose changes to and/or fix the flaws in greetd.
Situation
We currently use
greetd
with thegtkgreet
graphical frontend.Issues
This setup has several problems:
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 forgreetd
. This easily solves issues 1 & 2, but it turns out issue 3 is due to an API design flaw ingreetd
.Learned along the way
greetd
ICP protocol is unary. Meaning that every response message must be preceded by a request from the frontend.PAM
protocol is also unary but requests are initiated fromPAM
.greetd
frontends need a precise set of permissions to run. see install script: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
greetd
by polling some ICP request for state changes. Not entirely sure if this will work as it depends on the internals ofgreetd
.greetd
.