Description of problem:
/var/log/secure has lots of messages like this one:
"Jun 10 23:33:37 hermes su: PAM unable to dlopen(/lib64/security/pam_fprintd.so): /lib64/security/pam_fprintd.so: cannot open shared object file: No such file or directory
Jun 10 23:33:37 hermes su: PAM adding faulty module: /lib64/security/pam_fprintd.so
Jun 10 23:33:41 hermes su: pam_unix(su-l:session): session opened for user root by ciupicri(uid=500)"
Version-Release number of selected component (if applicable):
coreutils-7.2-1.fc11.x86_64.rpm (the package for su)
Steps to Reproduce:
1. $ exec su -
PAM errors in /var/log/secure
no PAM errors in /var/log/secure
I haven't changed any PAM configuration, or any other authentication/authorization setting. I'm using the default settings.
In spite of those errors su is running fine. I haven't noticed any problems yet.
This is certainly not a bug in PAM.
Either disable Fingerprint authentication in the system-config-authentication dialog or install fprintd-pam package.
This seems to be a bug somewhere, but not necessarily related to the package.
/var/log/secure reports a problem of a faulty PAM module (/lib64/security/pam_fprintd.so). This is a link, which points to "pam_fprintd.so.0.0.0".
The rpm package, however, does include the actual pam-module. Reinstalling the single package solves the problem.
(In reply to comment #2)
> /var/log/secure reports a problem of a faulty PAM module
> (/lib64/security/pam_fprintd.so). This is a link, which points to
$ ls /lib64/security/pam_fprintd*
ls: cannot access /lib64/security/pam_fprintd*: No such file or directory
This is a bug in pam.
- I do not have a fingerprint reader.
- I do not have fprintd-pam package installed.
pam package contains config files that reference files provided by fprintd-pam. That is broken.
This is a minimal install without X libs or gtk; I cannot install system-config-authentication.
No, it is not. PAM contains only one file referencing the pam_fprintd - /etc/pam.d/fingerprint-auth, but this file is not used on system without gdm. Anaconda probably called authconfig (command line utility which does not need X or gtk) to configure pam_fprintd to system-auth.
Hmmm. I did a minimal text install (i.e. linux text in installer boot prompt). Default text install (no GDM, no X) ended up with pam configured to use fprint. I assume that would be an anaconda bug then?
I have also seen this exact same problem in the same circumstances. Minimum text install for my home server and get the /lib64/security/pam_fprintd.so in /var/log/secure with no manual config changes.
I've just tried running authconfig --disablefingerprint --update and this has removed the pam_fprintd.so references in /etc/pam.d/system-auth and /etc/pam.d/system-auth-ac but not in /etc/pam.d/fingerprint-auth or /etc/pam.d/fingerprint-auth-ac.
Let's see if this stops the errors appearing.
Just for anyone reading this bug after searching teh internetz for the /lib64/security/pam_fprintd.so error, running
authconfig --disablefingerprint --update
does indeed fix the problem (for text installations at least)
*** Bug 518056 has been marked as a duplicate of this bug. ***
I didn´t the authconfig.
I just did yum -y install fprintd-pam and that solve the error messages, this really fiz the message erro.
(In reply to comment #11)
> I didn´t the authconfig.
> I just did yum -y install fprintd-pam and that solve the error messages, this
> really fiz the message erro.
(I have Fedora-13-LXDE installed).
I did the same but it caused my login session to freeze up. I could log out but I couldn't restart or shutdown. I did have mouse support though.
* gnome-keyring-daemon was looking specifically for org.gnome.sessionmanager which I don't have because I'm using lxsession.
* xscreensaver couldn't find my password. I think it was looking for a fingerprint - just a guess.
Anyway I removed it.
Just got this too.
[root@nohats ~]# grep pam_fprintd /etc/pam.d/*
/etc/pam.d/fingerprint-auth:auth sufficient pam_fprintd.so
/etc/pam.d/fingerprint-auth-ac:auth sufficient pam_fprintd.so
/etc/pam.d/system-auth:auth sufficient pam_fprintd.so
/etc/pam.d/system-auth-ac:auth sufficient pam_fprintd.so
[root@nohats ~]# rpm -qV pam
....L.... c /etc/pam.d/fingerprint-auth
....L.... c /etc/pam.d/password-auth
....L.... c /etc/pam.d/smartcard-auth
....L.... c /etc/pam.d/system-auth
yum reinstall pam did not work. And no .rpmnew file was there. But the following worked:
mv /etc/pam.d/system-auth /tmp
yum reinstall pam
[root@nohats ~]# grep fprintd /etc/pam.d/system-auth
So perhaps something in the upgrade path causing this
If I remember correctly, I had similar issues in Fedora 35 and I did something (like uninstall the package) to solve this problem.
Now I'm facing a similar problem when I upgraded to Fedora 36.
Message: PAM unable to dlopen(/usr/lib64/security/pam_fprintd.so): /usr/lib64/security/pam_fprintd.so: cannot open shared object file: No such file or directory
Message: PAM adding faulty module: /usr/lib64/security/pam_fprintd.so
The problem is that PAM is NOT smart enough to recognize that there is no hardware that allows users to use "fingerprint" functionality.
When we don't have such hardware (i.e scanner), WHY we are getting those errors?
Can't we fix the problem by PAM a bit smarter?
The objective of PAM is to authenticate users. As there are many different methods of doing that, each system can be configured (/etc/pam.d) to provide the best way of doing that.
You are getting those errors because the PAM stack (/etc/pam.d) contains at least one reference to pam_fprintd.so and this is why it tries to use this library to authenticate the user. I'd recommend you to review the stack on your system for a reference to pam_fprintd.so. Once this is done you could investigate why the reference is there.
Another option is to use the workaround provided in comment#9: authconfig --disablefingerprint --update
In conclusion, PAM authenticate users and the methods for doing so can be configured in the PAM stack. PAM should never check if the "fingerprint" hardware is present to decide if this functionality can be used.
(In reply to Iker Pedrosa from comment #15)
> Another option is to use the workaround provided in comment#9: authconfig
> --disablefingerprint --update
I tried using this command, but it doesn't work:
⟹ authconfig --disablefingerprint --update
bash: authconfig: command not found...
⟹ sudo authconfig --disablefingerprint --update
sudo: authconfig: command not found
Neither there is any package related to it:
⟹ sudo dnf install authconfig
Error: Unable to find a match: authconfig
⟹ dnf search authconfig
Last metadata expiration check: 2 days, 14:51:34 ago on Thu 21 Apr 2022 03:23:43 PM +0545.
No matches found.
So I was wondering if everyone has to go through this...
> Authselect replaced authconfig tool in Fedora 28. To enable some level of backwards compatibility, it ships the authconfig command as a wrapper around authselect calls in package "authselect-compat". Authselect is now well adopted and the shim compatibility layer should be removed by removing the authselect-compat package.
For all people who landed looking for some solution, who are using Fedora 36 or never (or even some older releases), use this command:
sudo authselect disable-feature with-fingerprint
After a lot of Google search, I found the command here: https://github.com/authselect/authselect/issues/207#issuecomment-624601710
(I still wonder who is ACTUALLY responsible for these errors/warnings and when they will be addressed. This is already too old.)