Authentication through fprintd breaks the interface and is unusable

[mskiptr]

 * slick-greeter 1.3.2
 * Manjaro 20.1
 * Intel 2nd Generation Core Processor Family Integrated Graphics; `video-linux` I guess?
 * 64 bit

Since I am using fingerprint authentication through fprintd, I have added appropriate entries in /etc/pam.d/. But there are several issues with how slick-greeter handles such login methods:

• The output of pam module can easily overflow horizontally, resulting in unreadable messages.
• Several lines of output result in vertical overflow of new text as well as of the control elements – buttons, input fields, etc. Then it's impossible to determine if the fingerprint was accepted, if we the user is asked for another attempt or if the password login was activated.
• Successful authentication still requires user input, like clicking the login button or – especially if it overflowed – blindly doing so with keyboard.
• User cannot easily pick whichever authentication method he sees fit but is presented with one option at the time. Switching to e.g. password login is unintuitive and unreliable at best. (Pressing esc sometimes switches, sometimes restarts the fprintd and sometimes seems to do nothing.) Preferably all the authentication methods would be active at once.

On the other hand, cinnamon-screensaver seems to handle it somewhat better. Maybe it would be possible to share this piece of logic between both tools?

screenshots

    

[okkindel]

+1

[noisystuff]

Hi

I found exactly that when using Ubuntu based Linux Mint and I spent quite a while trying to find out whether the login area could be expanded, but I eventually gave up on that idea. I initially got around it by limiting the quantity of failures (tweaking the /etc/pam.d/common-auth file) before it toggled to password, but that still wasn't really an ideal solution. Below shows the changes I made (I just commented the existing lines in case I had to use a Linux boot dish and vim to comment out my own and restore the existing ones, but it all worked fine).

# I commented out original lines (added by pam-auth-update)
# auth  [success=2 default=ignore]  pam_fprintd.so max_tries=1 timeout=10 # debug
# auth  [success=1 default=ignore]  pam_unix.so nullok try_first_pass
# I added below lines (so password can be used if fingerprint fails)
auth    [success=2 default=ignore]  pam_fprintd.so max_tries=3 timeout=3
auth    [success=1 default=ignore]  pam_unix.so nullok_secure

I ended up installing lightdm-gtk-greeter and in Ubuntu based Mint, I had to edit /usr/share/lightdm/lightdm.conf.d/90-slick-greeter.conf and change the contents from greeter-session=slick-greeter to greeter-session=lightdm-gtk-greeter. Once I'd done that, the new greeter worked and I could then restore /etc/pam.d/common-auth to use the original entries (i.e. the ones that pam-auth-update created after enabling the fingerprint line, so I deleted all my modifications shown above and when running sudo pam-auth-update, it no longer 'complains' about the file being user modified) and it's all now working reasonably well.

Incidentally, have noticed that the CLI fingerprint reading (e.g. when using sudo) is very reliable, but that the GUI fingerprint (at reboot login or screen lock login) often requires 2 or 3 attempts. The main thing is that if I get it wrong a few times (e.g. by purposely using the wrong finger) it does now enable me to enter the password in the password field (the field is there all the time, but it's not accessible until you get a few failures and thus it times out, but that's okay) so I now have the fallback to password system that I wanted (in case I accidentally chop my finger off, for example). ;-)

Hope some of that is of use to anyone else who chances across this thread.

[rmwiseman]

I'm surprised that it's now nearly April 2023 and this issue is still open!

I'm living with this issue too, and whilst it's not intolerable, it is annoying. I find if I move up and down the user list at login using the cursor keys, sometimes when I land on my username it displays correctly but it does seem quite random, like there are race conditions at play.