Bug 1942443

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.

Interestingly, I've recently had exactly the same problem on F33 (without upgrade). Could the bug get there too?

$ rpm -qa | grep authsel
authselect-libs-1.2.3-1.fc33.x86_64
authselect-1.2.3-1.fc33.x86_64
authselect-compat-1.2.3-1.fc33.x86_64

I also have nsswitch.conf.bak|rpmnew, although I don't think this laptop ever had F27 installed.

I had to un-enroll my keys from fprintd in the text console to be able to log in graphically (it's MATE, so lightdm).

Do you think it's the same issue?

I updated to F34 just a few days ago and I ran into the bug as well.
I did not find this bug report till now, so I helped myself with : https://help.gnome.org/admin/system-admin-guide/stable/login-fingerprint.html.en

just to be sure, this is the fix?

  authselect select sssd with-fingerprint with-silent-lastlog --force

and I think you are right, my Notebook has Fedora installed since F24 or F25

FEDORA-2021-48ca6e6b86 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-48ca6e6b86

(In reply to Geoffrey Marr from comment #22)
> 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.

I'm going to repropose this issue because we were only partially correct about the scope of the bug at the time it was classified RejectedBlocker. We since discovered that Fedora has automatically edited nsswitch configuration outside authselect at some point in the past, and therefore we expect all or most upgraded systems to be affected.

We already have a proposed solution, and I understand we're going to have another release slip anyway due to an unrelated issue, so it makes sense to not introduce an upgrade cliff when we can reasonably avoid it.

(In reply to Fedora Update System from comment #36)
> FEDORA-2021-48ca6e6b86 has been submitted as an update to Fedora 34.
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-48ca6e6b86

Ah, I guess there's no point if we have an update and a freeze exception already. Benjamin, is that update enough to close this issue?

Yes, I believe the submitted update is enough to fix this issue for all users.

FEDORA-2021-48ca6e6b86 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-48ca6e6b86`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-48ca6e6b86

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

(In reply to Michael Catanzaro from comment #38)
> Ah, I guess there's no point if we have an update and a freeze exception already.

There is a point. That update is not stable and it's not verified whether it fixes the problem (btw, my home desktop system was also affected by this issue, but I fixed it manually before the update was available). Re-proposing as a blocker per comment 37.

I wanted to test the fix. I modified /etc/authselect/nsswitch.conf so that `sudo authselect apply-changes` would fail with "[error] [/etc/authselect/nsswitch.conf] has unexpected content!". Then I installed the update from comment 40. However, the file was not regenerated and `sudo authselect apply-changes` still fails with the same error. Is that expected? I thought the update would force-select the right profile and regenerate the config files.

Not quite. What it does is update the file if it is not being managed by authselect.

What seems to be your case is that authselect is technically managing /etc/pam.d/fingerprint-auth, but it doesn't do anything because /etc/authselect/nsswitch.conf has been modified by a different package.

So … still stuck in a way.

Pavel, could we maybe get authselect to not refuse updating the rest if only nsswitch.conf has been modified?

Is that a case that's likely to actually exist?

FEDORA-2021-48ca6e6b86 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

(In reply to Adam Williamson from comment #44)
> Is that a case that's likely to actually exist?

In the past I edited (just) nsswitch.conf because nss-mdns didn't update it automatically (I think it even contained instructions that users should do so). Ever since then I carried the config file forward (I didn't even know that it should be automatically managed by authselect, until this bug). I don't know whether it could cause a login failure like demonstrated in this bug.

I'll reopen the bug because the conversation is still ongoing, so that we don't lose it from our blocker tracking systems.

Hmm, the file should have a header like:

# Generated by authselect on Fri Apr  9 11:15:22 2021
# Do not modify this file manually.

# If you want to make changes to nsswitch.conf please modify
# /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'.

Which does give the instructions that users should not manually modify nsswitch.conf, but should rather be editing /etc/authselect/user-nsswitch.conf.

Yes, the message is there *now* :-) But I was mostly referring to this quote from comment 30:
> 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.
where nss-mdns possibly edited the file directly. And in one case it didn't (a bug I suppose), so I had to figure it out and do it manually (very vague memories here). Even if I didn't, I'd still have the config file modified by the package on my other systems.

Btw, I looked at F27 and authselect is not there. It is at F28, but the warning message contains only the first two lines from comment 47 and definitely anything about user-nsswitch.conf. It also doesn't contain mdns4_minimal in hosts:, while nss-mdns is installed by default. But mdns4_minimal is present in F29 and later. So perhaps it was F28 where I needed to manually edit nsswitch.conf? Also interestingly, nsswitch.conf.bak is present on all live images (F28 up to F34).

I don't know what to make out of all this, I hope you do :-) I'm just trying to make sure the login issues (or any other issues, stemming from diverging configs carried from previous releases) won't impact a non-trivial portion of our userbase.

If we assume that a sizeable amount of people have custom nsswitch.conf because of past nss-mdns behavior (it would be nice to have this confirmed, it might have affected just certain installation paths, like netinst, or upgrades), do you believe such situation is OK for the moment, or should we do something about it now, before F34 is out?

(In reply to Kamil Páral from comment #48)
> If we assume that a sizeable amount of people have custom nsswitch.conf
> because of past nss-mdns behavior (it would be nice to have this confirmed,
> it might have affected just certain installation paths, like netinst, or
> upgrades), do you believe such situation is OK for the moment, or should we
> do something about it now, before F34 is out?

That's for blocker bug process to decide. Here we only need to decide how to fix the issue robustly. I stand by my earlier suggestion that RPM scriptlets should always call 'authselect -f' to clobber any user configuration made outside authselect.

Anecdata: my laptop was originally installed with F28 and I have all five lines of comment 47.

(In reply to Michael Catanzaro from comment #49)
> [SNIP]. I stand by my earlier suggestion that RPM scriptlets
> should always call 'authselect -f' to clobber any user configuration made
> outside authselect.

Yes, we really really should just be doing that. Personally, my only concern is that doing so technically requires a fedora change request.

It is just a matter of time until we need to force this on all users. Doing it now rather than waiting for F35 would simplify matters a lot.

Well, then perhaps this would be a hot candidate for a FeSCo decision.

Benjamin, is the existing fix sufficient to ensure users are always able to log in? Users unable to login is the blocker issue here.

If the current update is sufficient to ensure users can always log in, then 'authselect -f' can be handled later in a non-blocker bug.

(In reply to Kamil Páral from comment #42)
> I wanted to test the fix. I modified /etc/authselect/nsswitch.conf so that
> `sudo authselect apply-changes` would fail with "[error]
> [/etc/authselect/nsswitch.conf] has unexpected content!". Then I installed
> the update from comment 40. However, the file was not regenerated and `sudo
> authselect apply-changes` still fails with the same error. Is that expected?
> I thought the update would force-select the right profile and regenerate the
> config files.

Can you log in?

So … there might be some confusion, because I have personally focused on the PAM configuration issue.

We can fix the fact that you cannot login in gnome-shell. See https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3853

I had been hoping that Marco would get around to look into it properly. Doing the change suggested in the ticket should fix the problem. People will still see a message that fingerprint auth failed, but at least they can continue after that. i.e. it would fix the release critical aspect of this issue.

Can you do a build with a downstream patch for now, please?

(In reply to Michael Catanzaro from comment #53)
> Can you log in?

In my concrete test scenario, yes. I don't know how to reproduce a broken state (especially now with the fingerprint pam update already stable).

Scratch build:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=66552770

Pull request for gnome-shell package:
  https://src.fedoraproject.org/rpms/gnome-shell/pull-request/11

I am not entirely confident with just pushing this. Ideally at least Ray or Marco had a quick look whether it is sane.

OK, new scratch build:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=66554820

This now has the rubber stamp from Ray. So probably good to go in. PR for the package is updated.

Upstream MR (maybe Marco will comment there):
  https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1821

With this, affected users will see a message "Sorry, fingerprint authentication didn't work. Please try again." pop up multiple times. However, they can still use the login prompt without further issues.

Rejected as a blocker in the (currently running) F34 Go/No-Go meeting:
We can't be sure no one will hit this, but it does not violate the criteria as written. There is a known broad spectrum fix for f34 where we just make login work even if the config is in the bad state

Note, rejected as a blocker doesn't mean we don't want to fix it. It would still be very great to have a 0-day fix for this. It doesn't need any special status for that; the fix just needs to be submitted for stable by Monday or so. I will look at the PR shortly.

FEDORA-2021-cd4d2064ac has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-cd4d2064ac

FEDORA-2021-cd4d2064ac has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-cd4d2064ac`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cd4d2064ac

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Works great here :)

FEDORA-2021-cd4d2064ac has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Hello, 

I upgraded from Fedora 33 to Fedora 34, have gnome-shell-40.0-4.fc34 installed and still encounter this issue

I have all of the latest f34 updates installed and are still seeing this issue. Sometimes I have to reboot several times before it stops complaining about the fingerprint auth.

The fix does *not* address the underlying error of failing fingerprint auth. But it allows you to continue by simply typing in the password and hitting enter.

i.e. it looks the same, but password auth should be working now.

I wish it did :-) 

But it won't let me type much before it shows the fingerprint error. I've tried to out-type the error with no luck. It quickly shows the error and won't let me log in. After a few reboots I can, but it's really annoying.

Yikes, something must have messed up during my testing, and I have no idea what exactly.

You are right, the entry becomes insensitive. This should not happen, and I am not entirely sure why it does even.

Let me know if you need any kind of logs (and how to get them) from me, and I'll attach it here.

Benjamin has another gnome-shell update coming, but ultimately it is just a workaround. For a proper fix, we agree that the authselect package must always run 'authselect -f' or authselect should default to -f. Trying to respect user configuration might seem nice, but it's clearly too fragile. authselect needs to win if it is enabled. Reassigning to authselect.

The new update is: https://bodhi.fedoraproject.org/updates/FEDORA-2021-734b404996

(In reply to Michael Catanzaro from comment #71)
> For a proper fix, we agree that the authselect package must
> always run 'authselect -f' or authselect should default to -f. Trying to
> respect user configuration might seem nice, but it's clearly too fragile.
> authselect needs to win if it is enabled. Reassigning to authselect.

Note, it's also good to keep in mind the rpm configuration handling. On my system, I had a lot of .rpmnew files in /etc/authselect. I'm not sure how exactly the whole system works and when they are created. But if the updated config files don't overwrite the old ones, then forcing a profile update might have no effect.

The new update works for me. Still seeing the fingerprint error message, but I can reliably log in. At least the handful of times I tried :-)

Added a CommonBugs entry:
https://fedoraproject.org/wiki/Common_F34_bugs#login-authselect-fingerprint-error

Devs, please verify that instructions are correct, thanks.

Thanks Kamil! The instructions look good to me.

Benjamin, I got confused from all the comments here. Is this still an issue? Can you summarize what has been done and what is needed from authselect? Thank you.

In longterm, I will try to push and make authselect mandatory so that there are no longer collisions and we are able to deliver PAM changes to all users easily.

Kind of understandable.

So, what we have now is:
 1. We update pre-authselect configurations in the PAM package
 2. We have a workaround in gnome-shell that means that affected people only see an error message.

Unfortunately, we do have users with "authselect" configurations, where local modifications were made later on. It is not clear to me why this happens, but I suspect in most cases scripts modified e.g. /etc/nsswitch.conf. One user reported for example that they ran "ipa-client --install", which might be breaking things.

For F34, we do have a working solution with the gnome-shell update (not perfect, but really good enough).

For F35, it would be nice to have the change that makes authselect mandatory. I believe making that change is the only thing left at this point.

(In reply to Benjamin Berg from comment #78)
> For F35, it would be nice to have the change that makes authselect
> mandatory. I believe making that change is the only thing left at this point.

Making it mandatory in a sense that it cannot be uninstalled/switched off so it can be safely used will require more time to prepare and unfortunately I won't have time for it now, so this is F36.

But perhaps we can make a more simple change for F35 something like if authselect package is upgraded/installed on non-authselect configured systems then enforce the default configuration.

tbh I don't see any reason that we would need mandatory authselect.

What we need is for RPM scriptlets to use 'authselect -f' if authselect is enabled. If authselect is not enabled, that's fine. The problem is having authselect enabled with local customizations made outside authselect to the files it manages, where authselect currently breaks. We should not allow that. When authselect is enabled, user changes to the configuration files that it manages should be wiped away.