Hide Forgot
Created attachment 1765904 [details] journalctl -b Description of problem: At the GDM prompt, selecting my user results in "Sorry, fingerprint authentication didn't work. Please try again." Providing the correct password results in a slight delay, then the same message repeats. Version-Release number of selected component (if applicable): gdm-40~rc-1.fc34.x86_64 How reproducible: Happens every time (but I have not tried a restart) Steps to Reproduce: 1. Have Fedora 33 on a device with a fingerprint reader, but no fingerprints added. 2. Upgrade to Fedora 34 using dnf system-upgrade 3. Try to log in with a password Actual results: "Sorry, fingerprint authentication didn't work. Please try again." (even before providing a password, but also after providing one). Expected results: Successful login. Additional info: Strangely, switching to a different virtual console works. Login does not try to use the fingerprint reader, and the password is accepted. This is how I am able to write this bug report. I have never set up fingerprints; I am not a huge fan of single-factor biometric authentication.
This sounds very serious, marking as a proposed blocker, in case we can debug/reproduce this.
Created attachment 1765925 [details] List of installed packaged
Removing fprintd-pam (which autoremoves libfprint and fprintd) resolves the problem.
When removing fprintd: [error] [/etc/authselect/nsswitch.conf] has unexpected content! [error] Unexpected changes to the configuration were detected. [error] Refusing to activate profile unless those changes are removed or overwrite is requested. Unable to disable feature [17]: File exists I will attach nsswitch.conf
Created attachment 1765927 [details] /etc/authselect/nsswitch.conf
Created attachment 1765928 [details] Output from removal of fprintd-pam That one happens reliably if I undo and redo the removal of fprintd-pam.
I see simmilar issues, but with the lock screen. After I lock the screen I either see a blank screen with no photo, name and such. I can input but it will not succeed. In other cases I see the proper lock screen, but both password and fingerprint fails. To login after the screen is locked, I have to click the switch user, select the same user and login.
Had the same issue using a Lenovo Thinkpad P15 Gen1. Before I had Fedora silverblue 33 installed and no fingerprint sensor configured (the option just does not appear in fedora 33 silverblue even though it is available in workstation for my laptop). After upgrading to fedora silverblue 34 I was unable to login because of the mentioned fingerprint error message which reappeared in some form of a loop every few seconds and deleted the entered password. Entering the password fast enough and pressing entered before it was deleted by the "Sorry, fingerprint authentication didn't work. Please try again." did not work out too. Working fedora silverblue 33 Deployment: Version: 33.20210326.0 (2021-03-26T00:52:21Z) BaseCommit: da512b217d2b1dac0dfd23ba8e433b7f00fce3ab2d5e65f3dac68ab646e22bcc GPGSignature: Valid signature by 963A2BEB02009608FE67EA4249FD77499570FF31 LayeredPackages: akmod-nvidia fedora-workstation-repositories podman-compose xorg-x11-drv-nvidia zsh LocalPackages: rpmfusion-nonfree-release-33-1.noarch rpmfusion-free-release-33-1.noarch Pinned: yes Fedora 34 Deployment where I was unable to login: ostree://fedora:fedora/34/x86_64/silverblue Version: 34.20210326.n.0 (2021-03-26T08:08:45Z) BaseCommit: 61e157e8e9dc56962b2881e51c4578d082d9c10eee51f58ba1ad1bf4a731f8ce GPGSignature: Valid signature by 8C5BA6990BDB26E19F2A1A801161AE6945719A39 Diff: 1245 upgraded, 13 downgraded, 61 removed, 42 added LayeredPackages: akmod-nvidia fedora-workstation-repositories podman-compose xorg-x11-drv-nvidia zsh LocalPackages: rpmfusion-nonfree-release-34-0.2.noarch rpmfusion-free-release-34-0.3.noarch
Tried to remove fprintd-pam from the fedora silverblue 34 base image as mentioned above: ostree://fedora:fedora/34/x86_64/silverblue Version: 34.20210326.n.0 (2021-03-26T08:08:45Z) BaseCommit: 61e157e8e9dc56962b2881e51c4578d082d9c10eee51f58ba1ad1bf4a731f8ce GPGSignature: Valid signature by 8C5BA6990BDB26E19F2A1A801161AE6945719A39 Diff: 1245 upgraded, 13 downgraded, 61 removed, 41 added RemovedBasePackages: fprintd-pam 1.90.9-2.fc34 LayeredPackages: akmod-nvidia fedora-workstation-repositories podman-compose xorg-x11-drv-nvidia zsh LocalPackages: rpmfusion-nonfree-release-34-0.2.noarch rpmfusion-free-release-34-0.3.noarch But I still got the "fingerprint" error and was unable to login after reboot.
I was able to login now: - Switched to Screen Keyboard - With Screen keyboard enabled the problem disappeared - Entered password - Created fingerprint Now having a fingerprint registered I am able to login without problems.
Can affected folks say what versions of authselect and authselect-libs are installed? Thanks!
On my system I have the following versions installed: > rpm -qa | grep authsel authselect-libs-1.2.2-6.fc34.x86_64 authselect-1.2.2-6.fc34.x86_64
Could you try running "authselect apply-changes"? https://bugzilla.redhat.com/show_bug.cgi?id=1933520#c46 suggests that we are dealing with local modifications to /etc/nsswitch.conf (or some other files), which prevent the pam configuration to be updated and fixed.
Discussed during the 2021-03-29 blocker review meeting: [0] The decision to delay the classification of this as a blocker bug was made as this seems serious, but benzea believes it's the same as #1933520 and should have been fixed already. If it is not, we need to figure out under what circumstances that fix isn't working before we can decide if the impact is wide enough to be a blocker. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-03-29/f34-blocker-review.2021-03-29-16.00.txt
authselect apply-changes [error] [/etc/authselect/nsswitch.conf] has unexpected content! [error] Unexpected changes to the configuration were detected. [error] Refusing to activate profile unless those changes are removed or overwrite is requested. Some unexpected changes to the configuration were detected. Use 'select' command instead.
I have the same versions of authselect as Meinert Schwartau. rpm -qa | grep authsel authselect-libs-1.2.2-6.fc34.x86_64 authselect-1.2.2-6.fc34.x86_64 authselect-compat-1.2.2-6.fc34.x86_64
When I ran the command I got the following output: > sudo authselect apply-changes No existing configuration detected.
As I said, after registering a fingerprint for my user the problem disappeared. But I added a new user so that I have two users now. I just found out that if I click "switch user": - and click on the user for whom I added a fingerprint I see the message "(or place finger on reader)" and am able to login without hassle - and click on the newly created user I get the "Sorry, fingerprint ..." error again. The newly created user was a admin user with password provided.
> [error] [/etc/authselect/nsswitch.conf] has unexpected content! > [error] Unexpected changes to the configuration were detected. > [error] Refusing to activate profile unless those changes are removed or overwrite is requested. This means that nsswitch.conf was modified outside authselect therefore authselect will not touch it so it does not overwrite user changes. The file that you attached looks like default glibc. Is there perhaps any /etc/nsswitch.conf.bak or .rpmold? > No existing configuration detected. This means that you never opt-in into authselect configuration. To recover from both issues and restore system default use: authselect select sssd with-fingerprint with-silent-lastlog --force fprintd should expect possible authselect failure and produce a graceful error message that would be more helpful in fprintd context instead of the authselect error.
(In reply to Pavel Březina from comment #19) > > [error] [/etc/authselect/nsswitch.conf] has unexpected content! > > [error] Unexpected changes to the configuration were detected. > > [error] Refusing to activate profile unless those changes are removed or overwrite is requested. > > This means that nsswitch.conf was modified outside authselect therefore > authselect will not touch it so it does not overwrite user changes. The file > that you attached looks like default glibc. Is there perhaps any > /etc/nsswitch.conf.bak or .rpmold? > > > No existing configuration detected. > > This means that you never opt-in into authselect configuration. > > To recover from both issues and restore system default use: > authselect select sssd with-fingerprint with-silent-lastlog --force > > fprintd should expect possible authselect failure and produce a graceful > error message that would be more helpful in fprintd context instead of the > authselect error. That fixed it :-)
Pavel, so what's the plan here? I think you talked about forcing a fix in the RPM scriptlets in cases where we know the prior fix doesn't get applied? Thanks!
Discussed during the 2021-04-05 blocker review meeting: [0] The decision to classify this bug as a "RejectedBlocker (Final)" and an "AcceptedFreezeException (Final)" was made as the consensus was that it's just too narrow in scope to see as a release blocker (we believe it affects systems that started as Fedora 27 or earlier, and systems where nsswitch configuration was changed outside of authselect). It is accepted as a freeze exception. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-04-05/f34-blocker-review.2021-04-05-16.02.txt
(In reply to Adam Williamson from comment #21) > Pavel, so what's the plan here? I think you talked about forcing a fix in AFAIK the issue is fixed by authselect-1.2.3. If Benjamin agrees, this BZ can be closed as duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1943406 > the RPM scriptlets in cases where we know the prior fix doesn't get applied? > Thanks! This BZ also describes a problem when users gets authselect error message when they removed fprintd. This error message is correct and authselect failure is expected in given cases. We talked this through with Benjamin and he should have some patch ready to provide a better error message for fprintd context.
So, I was hoping to have a solution for https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3853 Either way. I think the sensible thing here is to force-update the specific line in /etc/pam.d/fingerprint-auth from the RPM postinstall script. We'll still have a userbase that is excluded from authselect, which is really not great, but at least it is an easy way to paper over this issue.
(we believe it affects systems that started as Fedora 27 or earlier, and systems where nsswitch configuration was changed outside of authselect). Neither of these apply to my laptop. It was installed with Fedora 32 and nsswitch configuration was not manually changed from the default. I still do not understand why authselect refused to touch my nsswitch.conf.
(In reply to Benny Amorsen from comment #25) > (we believe it affects systems that started as Fedora 27 or earlier, OK, that's our bug then. Proposal: RPM scriptlets should just always use 'authselect -f'. If authselect is enabled, then user changes to nsswitch.conf outside authselect are invalid and should be corrected on upgrade. It may not necessarily be what the user necessarily wants to happen, but it should avoid gratuitously broken systems. (Disadvantage: if we run 'authselect -f' automatically, it kind of defeats the point of having the -f flag at all.)
(In reply to Benjamin Berg from comment #24) > So, I was hoping to have a solution for > https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3853 > > Either way. I think the sensible thing here is to force-update the specific > line in /etc/pam.d/fingerprint-auth from the RPM postinstall script. We'll > still have a userbase that is excluded from authselect, which is really not > great, but at least it is an easy way to paper over this issue. Wouldn't it be better to patch the default files in pam package? (In reply to Benny Amorsen from comment #25) > (we believe it affects systems that started as Fedora 27 or earlier, and > systems where nsswitch configuration was changed outside of authselect). > > Neither of these apply to my laptop. It was installed with Fedora 32 and > nsswitch configuration was not manually changed from the default. > > I still do not understand why authselect refused to touch my nsswitch.conf. Is there any nsswitch.conf.bak|rpmnew|rpmold or something like that? (In reply to Michael Catanzaro from comment #26) > (In reply to Benny Amorsen from comment #25) > > (we believe it affects systems that started as Fedora 27 or earlier, > > OK, that's our bug then. > > Proposal: RPM scriptlets should just always use 'authselect -f'. If > authselect is enabled, then user changes to nsswitch.conf outside authselect > are invalid and should be corrected on upgrade. It may not necessarily be > what the user necessarily wants to happen, but it should avoid gratuitously > broken systems. (Disadvantage: if we run 'authselect -f' automatically, it > kind of defeats the point of having the -f flag at all.) Ideally, rpm scriptlets should not touch PAM at all. It is too easy to break it and too difficult to do it right. Packages should rather document what needs to be done. Hopefully, we can enforce authselect configuration in the future which would solve things like these.
(In reply to Pavel Březina from comment #27) > Is there any nsswitch.conf.bak|rpmnew|rpmold or something like that? Yes, there is an nsswitch.conf.bak. I am not sure why that is relevant. The configuration in nsswitch.conf has come either from the default in the RPM or from authselect. Surely authselect should be able to handle either case?
So, I have an ancient installation here (currently F31, probably upgraded for longer than F27). 2019-09-30T14:59:40Z SUBDEBUG Upgraded: glibc-2.29-22.fc30.x86_64 ... 2019-09-30T19:33:34Z SUBDEBUG Upgrade: glibc-2.30-5.fc31.x86_64 2019-09-30T19:33:34Z SUBDEBUG Upgrade: glibc-2.30-5.fc31.x86_64 2019-09-30T19:33:34Z INFO warning: /etc/nsswitch.conf created as /etc/nsswitch.conf.rpmnew [root@ben-x1 log]# ls -l /etc/nsswitch.conf* -rw-r--r--. 1 root root 1757 Mar 28 2020 /etc/nsswitch.conf -rw-r--r--. 1 root root 1725 Mar 28 2020 /etc/nsswitch.conf.bak -rw-r--r--. 1 root root 1652 Sep 26 2019 /etc/nsswitch.conf.rpmnew So, 2020-03-28 the file was last modified, which coincides with an update of nss-mdns. And, looking into that package, it still contains: function mod_nss() { if [ -f "$1" ] ; then # sed-fu to add mdns4_minimal to the hosts line of /etc/nsswitch.conf sed -i.bak ' /^hosts:/ !b /\<mdns\(4\|6\)\?\(_minimal\)\?\>/ b s/\<\(files\( myhostname\)\?[[:blank:]]\+\)/\1mdns4_minimal [NOTFOUND=return] /g ' "$1" fi } FILE="$(readlink /etc/nsswitch.conf || echo /etc/nsswitch.conf)" if [ "$FILE" = "/etc/authselect/nsswitch.conf" ] && authselect check &>/dev/null; then mod_nss "/etc/authselect/user-nsswitch.conf" authselect apply-changes &> /dev/null || : else mod_nss "$FILE" # also apply the same changes to user-nsswitch.conf to affect # possible future authselect configuration mod_nss "/etc/authselect/user-nsswitch.conf" fi So, that probably explains where the nsswitch.conf modifications are coming from.
Of course we see that script knows about authselect and modifies /etc/authselect/nsswitch.conf instead if authselect is in use. That means that for some reason, authselect was not enabled at the time that the nss-mdns scriptlet was run. I also see nss-mdns didn't know about authselect until F30 though, while authselect was in use since F27. That's probably not good. So we've established that however this happened, it's Fedora's fault, not user error. That suggests we need to run 'authselect -f' at least once, ideally when upgrading F33 -> F34, to get back to a good state.
Yeah, forcing a run of "authselect -f" (and setting the "sssd" profile if no profile is selected), seems like the right thing here in principle. How could we do this for the F33 -> F34 upgrade? Would this happen in a script inside the authselect package or in some other location? The only caveat I see is, that theoretically there may be users who modified some of these files intentionally. But, that seems *very* unlikely and those users should be updating their setup to work with authselect anyway.
(In reply to Benjamin Berg from comment #31) > How could we do this for the F33 -> F34 upgrade? Would this happen in a > script inside the authselect package or in some other location? An authselect package scritplet seems like the simplest and least-fragile approach. > The only caveat I see is, that theoretically there may be users who modified > some of these files intentionally. But, that seems *very* unlikely and those > users should be updating their setup to work with authselect anyway. Or just disable authselect altogether. IMO if authselect is enabled, it should always win over clashing non-authselect configuration, i.e. any Fedora package scriptlets that run authselect should always use 'authselect -f'. But users can always have final say if they want via disabling authselect.
OK, my proposal now is the following: https://src.fedoraproject.org/rpms/authselect/pull-request/11 i.e. the run the code: FILE="$(readlink -f %{_sysconfdir}/pam.d/fingerprint-auth || echo %{_sysconfdir}/pam.d/fingerprint-auth)" %__grep -q '^auth[[:space:]]\+sufficient[[:space:]]\+pam_fprintd.so' $FILE && \ %__sed -i.bak -e 's/^auth[[:space:]]\+sufficient[[:space:]]\+pam_fprintd.so\(.*\)/auth [success=done default=bad] pam_fprintd.so\1/g' $FILE Which updates the file in-place if it still has "sufficient" in it (after running the usual upgrade routines). As is, it will only run in case authselect is not functional for some reason.