Created attachment 842768 [details] last and lastb output After a clean Fedora 20 install and updates applied, GDM always show failed attempts, even when the user is using the correct password. Initially this was happening with VTs logins, but after running "authconfig --updateall" like on Bug 1021108 the VTs part was fixed. "authconfig --updateall" locked but regenerated the files, See Bug 1047076 The GDM message still appears, to fast to be noticed, but it shows. After removing wtmp, btmp and lastlog and reboot, logged in a few times using GDM and lastb shows failed logins, all log ins where successful. See attached last and lastb output. Looks like every successful GDM login is adding a failed loging to btmp
Created attachment 843171 [details] Portion of audit.log The failure is recorded before the success PAM authentication, watching the output of lastb, the failure login is added when I select my user on gdm, but without entering the password, waiting on the password prompt, the failure is recorded. I compared all pam.d files with another installation that doesn't shows this behaviour and all files are the same. I disable fingerprint authentication on authconfig testing if it is related, that doesn't workaround anything (I don't use the fingerprint reader)
Finally it is fingerprint reader related, authconfig doesn't entirely disable fingerprint on gdm. I disabled it using dconf, in a new file: /etc/dconf/db/gdm.d/99-local [org/gnome/login-screen] enable-fingerprint-authentication=false then running "dconf update" This way the problematic fingerprint code is not triggered, no login failures are logged when I select my user Package versions: fprintd-0.5.1-1.fc20.x86_64 fprintd-pam-0.5.1-1.fc20.x86_64 gdm-3.10.0.1-1.fc20.x86_64 gdm-libs-3.10.0.1-1.fc20.x86_64 libfprint-0.5.1-1.fc20.x86_64 Fingerprint reader device: Bus 004 Device 002: ID 08ff:2810 AuthenTec, Inc. AES2810 No fingerprint enrolled, I don't use it. Now, I don't know if this happens on all devices with a supported fingerprint reader or it is only on my specific device. Another ThinkPad with an unsupported reader does not trigger this bug, probably because of it non being supported
It seems I was having the same bug, and the workaround from comment 2 works for me too. The machine here is a Thinkpad X230, the fingerprint reader is: Bus 001 Device 003: ID 147e:2020 Upek TouchChip Fingerprint Coprocessor (WBF advanced mode) I can live with the workaround; is there a better way to handle an unused fingerprint reader though, so that there are no bogus failed attempts that confuse people?
Same issue here. ThinkPad X220. Workaround from Comment 2 works here as well.
(In reply to Michael Reiger from comment #3) > It seems I was having the same bug, and the workaround from comment 2 works > for me too. This was only half the fix, as it turns out: I still had failed login counts correlated to the number of times I unlocked the screen saver. The following completed the workaround for me: I installed dconf-editor and disabled fingerprint authentication not only on a system level (see above) but also in my own user session: In dconf-editor I navigated to Org - Gnome - login-screen and unchecked the enable-fingerprint-authentication check box. (Of course this needs to be done with every user on the machine and is therefore a real pain if there is more than one user.)
does removing session include postlogin from /etc/pam.d/gdm-fingerprint make the problem go away?
After applying the workaround in Comment 2 I found I was still getting some false failed login messages as Michael Reiger stated in Comment 5 . It appears that adding the additional step of Comment 6 did make the problem go away. I did not try using dconf-editor, as I don't have an internet connection atm to install it.
Re: comment 6. removing the line from /etc/pam.d/gdm-fingerprint does not make the problem go away. Using Thinkpad X220 w all normal F20 updates.
Oh man, and I thought I was getting bruteforced or something. I have a Lenovo USB keyboard with a fingerprint reader (0483:2016 STMicroelectronics Fingerprint Reader) that I'm not using. Indeed, just by locking and unlocking my screen with my password, a new entry immediately appears in "lastb". "postlogin" is not present in my /etc/pam.d/gdm-fingerprint file. Here are its contents (didn't touch anything except remove blank lines): auth substack fingerprint-auth account required pam_nologin.so account include fingerprint-auth password include fingerprint-auth session required pam_selinux.so close session required pam_loginuid.so session optional pam_console.so -session optional pam_ck_connector.so session required pam_selinux.so open session optional pam_keyinit.so force revoke session required pam_namespace.so session include fingerprint-auth
I believe this is caused by this code: static void• on_authenticate_cb (GdmDBusWorker *proxy,• GAsyncResult *res,• gpointer user_data)• {• ... worked = gdm_dbus_worker_call_authenticate_finish (proxy, res, &error);• • ... if (worked) {• ... } else {• gdm_session_record_failed (conversation->worker_pid,• self->priv->selected_user,• self->priv->display_hostname,• self->priv->display_name,• self->priv->display_device);• • ... }• }• Basically we call into pam_fprintd and it fails authentication because the user doesn't have enrolled fingerprints. Since authentication failed, we record a btmp entry. possible fixes: 1) check if a user has enrolled fingerprints from gnome-shell before initiating a fingerprint authentication 2) potentially look at different error codes coming from PAM in GDM and only write btmp for certain types of authentication failures.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This still happens in F22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.