Red Hat Bugzilla – Bug 394181
krunner_lock/kcheckpass crashes when using thinkfinger
Last modified: 2009-04-27 14:19:46 EDT
Description of problem: I tried to use thinkfinger on my IBM Thinkpad Z61M. The package "thinkfinger" was installied via yum and I added pam_thinkfinger.so in /etc/pam.d/system-auth [...] auth sufficient pam_thinkfinger.so auth sufficient pam_unix.so nullok try_first_pass [...] This worked in F7 and seems to be fine in F8, too. I am able to use the fingerprint-reader in gdm in order to log in the system. However, when kde desktop is locked up (screen saver, or manually), it is not possible to login again. If the user is asked for his password and entering it correctly, a error message is displayed: "Aufheben der Sperre nicht möglich: Keine Authentifizerung möglich. Versuchen Sie den Prozess kdesktop_lock(pid 3886) manuell zu beenden) (I am trying to translate: Not possible to dislock: No authentification possible. Please try to kill the process kdesktop_lock (pid 3886) manually). The user is not able to login again and have to kill the process or remove the line in system_auth. Version-Release number of selected component (if applicable): thinkfinger.i386 0.3-7.fc8 kdebase.i386 6:3.5.8-5.fc8 How reproducible: Nearly always Steps to Reproduce: 1. install "thinkfinger" via yum 2. add "auth sufficient pam_thinkfinger.so" at line 5 at /etc/pam.d/system-auth 3. setup a valid fingerprint via tf-tool 4. Login as use in GDM using the fingerprint reader 5. Choose "lock session" 6. Try entering your password Actual results: The error message above is shown and login fails Expected results: the desktop is shown again. Additional info: I am not sure, if this is a problem in thinkfinger or kdebase. At least I didn't even know that kde session lock is using thingfinger also. However, at least typing in the user password should work to login. The system is up to date. I am adding the .xsession_error. Looks like the problem is a malloc problem tracing back to libc. If further test are needed, please lead me a hand.
Created attachment 266011 [details] .xsession-errors with possible trace back of the problem
Could you please change the line in your /etc/pam.d/system-auth to: auth sufficient pam_thinkfinger.so debug and then post any error messages that appear in /var/log/messages? Thanks.
Created attachment 266021 [details] /var/log/message after adding debug option to pam_thinkfinger.so
If you could also attach the appropriate fragment of /var/log/secure (with debug option still enabled), that would be great. Mike, Timo: can the Fedora-specific patches cause that?
Florian, nevermind, I can reproduce that here. For reference, /var/log/secure says : Nov 21 16:34:21 localhost kcheckpass[8284]: pam_thinkfinger(kscreensaver:auth): pam_sm_authenticate called. Nov 21 16:34:21 localhost kcheckpass[8284]: pam_thinkfinger(kscreensaver:auth): thinkfinger_thread called.
I did some testing and it turns out that dropping the device and fingerprint permission patches, the lockup is gone. Mike?
Could you with line : auth sufficient pam_thinkfinger.so in front of the line : auth required pam_env.so Have you try to add the pam line on /etc/pam.d/kscreensaver ? My two cents
Adding the thinkfinger line before pam_env does result in the same problem. Adding the line to kscreensaver does either work, nor leading to the problem. Not sure, but system-auth seems to be included in kscreensaver already.
Having the same problem, intermittently, on a T61p running FC8. I have had the fingerprint software installed for about two weeks. Occasionally saw some kind of auth failure when trying to dismiss the screensaver, but today I get the "authentication system failed ... kill kdesktop_lock" message and it doesn't want to "unstick"; I have to kill the process from a console window or ssh session. If I run kcheckpass in a terminal it works fine with both password entry via keyboard, as well as finger-swipe. If I run kdesktop_lock (with or without --forcelock) it brings up the screen saver but exits with the "X Error: BadAccess ..." messages that others report. kdebase-3.5.8-9.fc8 thinkfinger-0.3-7.fc8 /etc/pam.d/system-auth: auth required pam_env.so auth sufficient pam_thinkfinger.so try_first_pass auth sufficient pam_unix.so nullok try_first_pass ... /etc/pam.d/kscreensaver auth include system-auth ... password include system-auth ...
Confirmed on X61s with F9, on KDE with kdesktoplock, I get the following details: Dec 4 02:10:48 baumbart kernel: kcheckpass[10359]: segfault at 00000000 eip 002df1e9 esp b75621c0 error 4 I can't even use password to unlock the screensaver. But I cannot confirm, that kcheckpass works from terminal (I'll do some more testing).
Are there any news on this issue? The problem seems also exist with kde4. It would be nice, if at least the normal password would work.
really? Too bad, my hopes were, that kde4 would fully respect pam settings...
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
Still happens in Fedora 10 according to bug 474312.
*** Bug 474312 has been marked as a duplicate of this bug. ***
*** Bug 476485 has been marked as a duplicate of this bug. ***
triaged (assigned).
Why has this bug a severity of "low"? Is there an easy workaround for this? There are a lot of duplicates and all this is really annoying for a long time.
Per comment #10, if kcheckpass is crashing and is still reproducible please report upstream to bugs.kde.org.
Crash is occuring in kdebase-workspace, reassigning. (any additional thinkfinger-related help/insight/debugging advice welcome).
I never did any actual debugging into this; I was only maintainer for awhile and didn't have the time to research any of the bug reports in-depth.
Thank you for the bug report. This issue needs to be addressed by the upstream developers. Please submit a report at http://bugs.kde.org. You are requested to add the bugzilla link here for tracking purposes. Please make sure the bug isn't already in the upstream bug tracker before filing it.
The information we've requested above is required in order to review this problem report further and diagnose or fix the issue if it is still present. Since it has been thirty days or more since we first requested additional information, we're assuming the problem is either no longer present in the current Fedora release, or that there is no longer any interest in tracking the problem. Setting status to "CLOSED: INSUFFICIENT_DATA". If you still experience this problem after updating to our latest Fedora release and can provide the information previously requested, please feel free to reopen the bug report. Thank you in advance.