Description of problem: See: bug #'s 656040 and 505266 Given a minimal install, Anaconda configures fingerprint-auth in the base /etc/pam.d/system-auth file. This has been a reported problem since Fedora 11. Version-Release number of selected component (if applicable): Anaconda as installed for Fedora 11 - 14. How reproducible: 100% Steps to Reproduce: 1. install "minimal" package set 2. 3. Actual results: fingerprint-auth configured in system-auth, causing all auth methods that use system-auth (nearly everything....) to produce errors. Expected results: fingerprint-auth not configured unless someone installs pam_fprintd Additional info: from my comment in 656040: Example errors in /var/log/secure: Nov 22 21:58:43 servername sudo: PAM unable to dlopen(/lib64/security/pam_fprintd.so): /lib64/security/pam_fprintd.so: cannot open shared object file: No such file or directory Nov 22 21:58:43 servername sudo: PAM adding faulty module: /lib64/security/pam_fprintd.so No, it doesn't keep something from working. But it *does* pollute the /var/log/secure log with stuff that makes auditing need to have a rule added, and makes monitoring need an exception added, etc. Would be better for pam to just not create those files, and not include fprint: [me@here pam.d]# grep fprint /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
Is this not really anaconda? Is it just because the default for authconfig is "USEFPRINTD=yes" regardless whether pam_fprintd is installed? This is a long-standing issue spanning several releases. Given the releases involved, I wouldn't be surprised if it was an issue in RHEL6 as well (though, I do not have a RHEL6 system to check).
I'd really rather not change authconfig args based on installed packages, because I don't like the precedent that sets. It seems like it could just get very complicated in a big hurry. Is it not possible to just add pam_fprintd to the base install set?
sure, it's possible...but isn't it a much, much worse precedent to add packages to the base install set just to keep from changing a default value? Why does every single headless machine in a massive server farm need fingerprint scanners? Fedora/RedHat has gotten much better about this lately, now I don't see bluetooth stuff as part of the base minimal install anymore. I'd really rather not see "dependency hell" as it used to be called return for something simple like this. I'm just a guy though ;) When looking at a minimal install + authconfig, here's /etc/sysconfig/authconfig: USEMKHOMEDIR=no USEPAMACCESS=no CACHECREDENTIALS=yes USESSSDAUTH=no USESHADOW=yes USEWINBIND=no USEDB=no FORCELEGACY=no USEFPRINTD=yes FORCESMARTCARD=no PASSWDALGORITHM=sha512 USELDAPAUTH=no USEPASSWDQC=no USELOCAUTHORIZE=yes USECRACKLIB=yes USEWINBINDAUTH=no USESMARTCARD=no USELDAP=no USENIS=no USEKERBEROS=no USESYSNETAUTH=no USESSSD=no USEHESIOD=no It would seem to me that all of the non-no values are in keeping with what is actually a posix-compliant, minimal install; it isn't assuming you're using smart cards, it isn't assuming ldap, it isn't assuming samba, it it isn't assuming NIS...it's not even assuming sssd. It assumes you're using shadow passwords. It picks a hash method, etc. But it *does* assume fprintd; that seems like it was an oversight in the initial inclusion. That "USEFPRINTD=" setting should be changed from the default "no" to "yes" only if pam_fprintd is actually installed. I also think it shouldn't do "CACHECREDENTIALS=yes" since, with a minimal install, there isn't anything that *can* cache credentials (sssd, nscd, nslcd, etc). But at least that doesn't overflow the logs with errors :) The purpose of the bug report is to improve the quality of, and end-user experience with, Fedora. This has been reported as a problem for 4 versions now; I hesitate to go back and install something prior to Fedora11 to see if it was older than that. Wouldn't it truly be easier to just change that default value, than to add 11 packages (fprintd-pam + dependencies) to every headless cluster node out there? Especially considering that one of those packages is the very problematic "ConsoleKit" package, known for suddenly consuming resources on headless machines, and known for being hard to keep it from automatically starting? What is minimalistic about fingerprint scanning?
to be clear: most of the default settings for authconfig are what they should be, with only 2 exceptions. Of those 2, only 1 causes errors that spam the logs. "USELDAP=no" is presumably set to yes when it is actually needed. I'm just asking for what looks to have been an oversight at some point to be corrected; this shouldn't be seen as setting a precedent for changing default values to prevent issues in other tools, it should just be seen as correcting a default value to what it should have initially been, consistent with all the other default values in the same tool.
Okay, this should be fixed in the next build of anaconda.
*** Bug 665926 has been marked as a duplicate of this bug. ***
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping