Fingerprint timeout too short?

SoloRobo commented 3 months ago

Using an AMD Framework 13 it appears that the timeout for using the fiingerprint is quite short and it reverts to a password prompt (without focus) quite quickly.

0.1.0~^20240802.123458gitcc744b0 Fedora 40

mstarongithub commented 2 months ago

Can confirm this as well, using some HP Probook (HP 87ED) on Fedora 40 KDE spin and greeter at version 0.1.0~^20240822git17b554d

jotuel commented 2 months ago

This repository is for cosmic-greeter. I'm going to suggest you some more productive places to report this and a DIY solution. Homesite for fprint and git for it. Also finally we get to pam. Lastly Fedora 40 is a common thread here so may I also suggest their forum.

However if I peer into this from the Pop!_OS users perspective I notice: https://manpages.ubuntu.com/manpages/noble/en/man8/pam_fprintd.8.html and furthermore the contents of my /etc/pam.d/common-auth has this line: auth [success=2 default=ignore] pam_fprintd.so max-tries=1 timeout=10 # debug Now changing values 1 and 10 into 2 and 15 for example would give me more time and a second attempt.

mstarongithub commented 2 months ago

Sorry, but considering that both sddm (for screen unlock, not first login) and sudo (via pam) offer a lot more time before failing that check is, in my opinion, a valid argument against either Fedora, fprint or pam being the cause. Especially considering that I just discovered that greeter does actually wait for a fingerprint. But only after failing a password check while both sudo and sddm always correctly expect a fingerprint scan first. And pam has no special config for fprintd, no arguments provided to it

Here's the behaviour of sddm, sudo and cosmic-greeter:

sddm (first login): Asks for password, then waits for fingerprint scan (without a prompt which I should probably report to them), then login done
sddm (screen unlock): Asks for password OR fingerprint, no timeouts anywhere
sudo: Asks for fingerprint, no timeout, if canceled via ctrl-c, asks for password. Failed scan asks for fingerprint again for a total of 3 times
Greeter (screen unlock): Fingerprint prompt appears for at most half a second, then fails to password. Failing the password gives the fingerprint prompt again, but now properly waiting for input. Completing either that scan or the password before unlocks
Greeter (login): I don't know, haven't tried it for that, sddm does the job just fine

jotuel commented 2 months ago

As far as I understand sddm actually does not support fingerprint login based on this and the pull request not accepted. You, or the maintainer of Fedora's rpm, likely has patched this issue.

This is the relevant pam module. Your Sddm also uses this. But it also is distribution specific how everything works together because the packager can always modify the defaults. Pop OS for example comes without any of this installed or setup for you and the user must configure it.

cosmic-greeter just respects your pam configuration. If it says give fingerprint 3 attempts 15 seconds each and then fallback to password login then that is what is going to happen.

mstarongithub commented 2 months ago

Sure, lets take sddm out of the equation. Then why is sudo still behaving as expected and yet cosmic-greeter isn't? And don't tell me that's due to a custom build from me too. For neither sddm nor sudo I know how to even build them (or even where to get the source for sudo).

To me it's starting to feel like you want the issue to be anything else but cosmic-greeter, despite cosmic-greeter being the only missbehaving app in regards to that problem

jotuel commented 2 months ago

Have you checked contents of your /etc/pam.d/sudo file? Again the contents of these files vary distribution to distribution and even release to release. The process by which one can login as a regular user and gain root privileges are different. And I do not have a desire for there to be a flaw anywhere. I did not write cosmic-greeter and there sure are flaws in it and it still is incomplete as well.

It is a greeter though and greeter (in my opinion) must never be able to lax your login requirements, allow for more tries or add time to counters. Now I clearly can not convince you that without the code I have no clue what is going on your system or am otherwise unable to convince that Fedora with any COSMIC at this stage indeed qualifies as a custom build. But one more time for good measure: to be able to use sudo you authenticate with pam, to login you authentice with pam (yes even with cosmic-greeter) and for each of these pam checks the configuration files and then runs the show.

pub fn pam_thread(username: String, conversation: Conversation) -> Result<(), pam_client::Error> {
    //TODO: send errors to GUI, restart process

    // Create PAM context
    let mut context = pam_client::Context::new("cosmic-greeter", Some(&username), conversation)?;

    // Authenticate the user (ask for password, 2nd-factor token, fingerprint, etc.)
    log::info!("authenticate");
    context.authenticate(pam_client::Flag::NONE)?;

    // Validate the account (is not locked, expired, etc.)
    log::info!("acct_mgmt");
    context.acct_mgmt(pam_client::Flag::NONE)?;

    Ok(())
}

All the best.

dragoonz87 commented 1 month ago

I've been noticing a similar (I think) issue where, when I go to unlock my AMD FW 16, if it even asks for a fingerprint first, it is only briefly, then asks for a password. If that fails (e.g. I just press enter without typing in a password), then it asks for a fingerprint again and actually waits for an input.

Like the others mentioned, I have experienced no issues with sudo commands. There haven't even been issues when I first boot up the laptop, only when unlocking.

I'm running Pop!_OS jammy 22.04 x86_64 with cosmic-greeter version 0.1.0~1727456934~22.04~8e19b3f.

jotuel commented 1 month ago

Cosmic Epoch 1 release will not support fingerprint readers. What naturally follows is that cosmic-greeter, being a part of it, does not do so either. https://github.com/pop-os/cosmic-settings/issues/443#issuecomment-2315656319

...when I go to unlock my AMD FW 16...

This sounds like you have your user login page already open. On default you only get something like 10 seconds and 1 try. It is a 16 year old known fprintd issue:

pam_fprintd does not support identifying the user itself as that would mean having the fingerprint reader on for all the time the user selection is displayed, and could damage the hardware. It could be fixed by having gdm/login only start the PAM conversation when there is activity

We have the same hardware and software and it gets really hot if you let it. I suspect there is a reason for the limitation. Anyhow this is my /etc/pam.d/common-auth content.

dragoonz87 commented 1 month ago

Ah, ok. Thank you for the extra context!

pop-os / cosmic-greeter

Fingerprint timeout too short? #99