Bug 1942443 - Login using password failed after upgrade to Fedora 34
Summary: Login using password failed after upgrade to Fedora 34
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 34
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On:
Blocks: F34FinalFreezeException, FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2021-03-24 11:44 UTC by Benny Amorsen
Modified: 2021-04-12 01:43 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
journalctl -b (815.10 KB, text/plain)
2021-03-24 11:44 UTC, Benny Amorsen
no flags Details
List of installed packaged (90.24 KB, text/plain)
2021-03-24 12:49 UTC, Benny Amorsen
no flags Details
/etc/authselect/nsswitch.conf (2.13 KB, text/plain)
2021-03-24 12:57 UTC, Benny Amorsen
no flags Details
Output from removal of fprintd-pam (4.66 KB, text/plain)
2021-03-24 13:00 UTC, Benny Amorsen
no flags Details

Description Benny Amorsen 2021-03-24 11:44:03 UTC
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.

Comment 1 Kamil Páral 2021-03-24 12:10:46 UTC
This sounds very serious, marking as a proposed blocker, in case we can debug/reproduce this.

Comment 2 Benny Amorsen 2021-03-24 12:49:52 UTC
Created attachment 1765925 [details]
List of installed packaged

Comment 3 Benny Amorsen 2021-03-24 12:51:32 UTC
Removing fprintd-pam (which autoremoves libfprint and fprintd) resolves the problem.

Comment 4 Benny Amorsen 2021-03-24 12:55:29 UTC
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

Comment 5 Benny Amorsen 2021-03-24 12:57:22 UTC
Created attachment 1765927 [details]
/etc/authselect/nsswitch.conf

Comment 6 Benny Amorsen 2021-03-24 13:00:00 UTC
Created attachment 1765928 [details]
Output from removal of fprintd-pam

That one happens reliably if I undo and redo the removal of fprintd-pam.

Comment 7 mattias.eriksson 2021-03-24 13:44:19 UTC
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.

Comment 8 Meinert Schwartau 2021-03-27 07:42:55 UTC
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

Comment 9 Meinert Schwartau 2021-03-27 09:30:38 UTC
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.

Comment 10 Meinert Schwartau 2021-03-27 16:57:08 UTC
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.

Comment 11 Adam Williamson 2021-03-29 16:25:59 UTC
Can affected folks say what versions of authselect and authselect-libs are installed? Thanks!

Comment 12 Meinert Schwartau 2021-03-29 17:26:18 UTC
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

Comment 13 Benjamin Berg 2021-03-29 18:03:20 UTC
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.

Comment 14 Geoffrey Marr 2021-03-29 18:32:19 UTC
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

Comment 15 Benny Amorsen 2021-03-29 18:51:15 UTC
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.

Comment 16 Benny Amorsen 2021-03-29 18:52:41 UTC
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

Comment 17 Meinert Schwartau 2021-03-29 19:05:27 UTC
When I ran the command I got the following output:

> sudo authselect apply-changes
No existing configuration detected.

Comment 18 Meinert Schwartau 2021-03-31 06:44:29 UTC
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.

Comment 19 Pavel Březina 2021-03-31 14:03:07 UTC
> [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.

Comment 20 Meinert Schwartau 2021-03-31 16:45:15 UTC
(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 :-)

Comment 21 Adam Williamson 2021-04-05 16:23:11 UTC
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!

Comment 22 Geoffrey Marr 2021-04-05 23:46:21 UTC
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

Comment 23 Pavel Březina 2021-04-06 08:31:54 UTC
(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.

Comment 24 Benjamin Berg 2021-04-06 08:52:03 UTC
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.

Comment 25 Benny Amorsen 2021-04-06 09:07:38 UTC
(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.

Comment 26 Michael Catanzaro 2021-04-06 11:42:42 UTC
(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.)

Comment 27 Pavel Březina 2021-04-06 12:18:18 UTC
(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.

Comment 28 Benny Amorsen 2021-04-06 12:23:30 UTC
(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?

Comment 29 Benjamin Berg 2021-04-07 12:29:11 UTC
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.

Comment 30 Michael Catanzaro 2021-04-07 14:13:54 UTC
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.

Comment 31 Benjamin Berg 2021-04-07 15:08:29 UTC
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.

Comment 32 Michael Catanzaro 2021-04-07 15:37:27 UTC
(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.

Comment 33 Benjamin Berg 2021-04-09 10:35:51 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.