Hi,
On 3/1/21 9:15 PM, Ray Strode wrote:
Hi,
On Sun, Feb 28, 2021 at 9:46 AM Hans de Goede <hdegoede(a)redhat.com> wrote:
>>
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683
<
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
>> seems like this is already in updates. you definitely have the gnome-shell
40.beta installed? could be a pam_fprintd is returning a different error code than
expected for no enrolled fingerprint
So we've been investigating this in the above upstream link.
There is a case where pam_fprintd is returning a code we aren't
expecting, but, it shouldn't ever happen :-)
pam_fprintd checks up front if there are no enrolled fingerprints and
then returns the correct error code in that case.
You guys are apparently getting past that part and failing later.
Almost as if the prints were there and then a split second later
disappeared.
One theory is there are files present, but they're unreadable. Maybe
because of selinux?
Can you try in permissive mode, also output ls -lRZ /var/lib/fprint
permissive mode does not help
[hans@x1 linux]$ sudo ls -lRZ /var/lib/fprint
/var/lib/fprint:
total 0
> Any debugging options which I can enable somewhere to show the
pam_fprintd error ?
you can put "debug" on the ends of the lines that say pam_fprintd.so
in /etc/pam.d/fingerprint-auth
that should make the journal more chatty.
Ah, I think now we are getting somewhere. I have a script which I run to
tweak new / upgraded installs to lower the amount of services which are
running be default (mostly because of the 1G/2G RAM x86 Windows tablets
which I try to support as a side project). This script contains the following:
sudo authselect select minimal
sudo authselect apply-changes
Which results in the following /etc/pam.d/fingerprint-auth file:
[hans@x1 linux]$ sudo cat /etc/pam.d/fingerprint-auth
# Generated by authselect on Tue Mar 2 15:24:53 2021
# Do not modify this file manually.
[hans@x1 linux]$
I think that that probably has something to do with this. So I guess I somewhat
have myself to blame for this because of using non default settings (1).
Still it would be nice if we could get this to work again (as it did in F33 and
older).
Regards,
Hans
1) Although IMHO this should actually be the default sssd is nice for corporate
environments but in most cases it is totally unnecessary and adds a bunch of
overhead. But that is a different discussion.