Bug 394181 - krunner_lock/kcheckpass crashes when using thinkfinger
krunner_lock/kcheckpass crashes when using thinkfinger
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kdebase-workspace (Show other bugs)
10
All Linux
low Severity low
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
:
: 474312 476485 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-21 09:30 EST by Florian Sievert
Modified: 2009-04-27 14:19 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-27 14:19:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
.xsession-errors with possible trace back of the problem (7.92 KB, text/plain)
2007-11-21 09:30 EST, Florian Sievert
no flags Details
/var/log/message after adding debug option to pam_thinkfinger.so (4.24 KB, text/plain)
2007-11-21 10:03 EST, Florian Sievert
no flags Details

  None (edit)
Description Florian Sievert 2007-11-21 09:30:15 EST
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.
Comment 1 Florian Sievert 2007-11-21 09:30:15 EST
Created attachment 266011 [details]
.xsession-errors with possible trace back of the problem
Comment 2 Julian Sikorski 2007-11-21 09:41:21 EST
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.
Comment 3 Florian Sievert 2007-11-21 10:03:03 EST
Created attachment 266021 [details]
/var/log/message after adding debug option to pam_thinkfinger.so
Comment 4 Julian Sikorski 2007-11-21 10:30:06 EST
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?
Comment 5 Julian Sikorski 2007-11-21 10:39:24 EST
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.
Comment 6 Julian Sikorski 2007-11-21 11:17:58 EST
I did some testing and it turns out that dropping the device and fingerprint
permission patches, the lockup is gone. Mike?
Comment 7 Pierre-Yves 2007-11-27 10:54:39 EST
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
Comment 8 Florian Sievert 2007-11-27 12:39:45 EST
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.
Comment 9 T Snyder 2007-12-27 17:40:42 EST
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
  ...
Comment 10 Christof Kälin 2008-01-08 05:27:49 EST
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).
Comment 11 Florian Sievert 2008-04-22 16:03:54 EDT
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.
Comment 12 Christof Kaelin 2008-04-27 18:45:05 EDT
really? Too bad, my hopes were, that kde4 would fully respect pam settings...
Comment 13 Bug Zapper 2008-11-26 03:38:03 EST
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
Comment 14 Kevin Kofler 2008-12-03 06:01:43 EST
Still happens in Fedora 10 according to bug 474312.
Comment 15 Kevin Kofler 2008-12-03 06:02:08 EST
*** Bug 474312 has been marked as a duplicate of this bug. ***
Comment 16 Ian Amess 2008-12-15 06:08:08 EST
*** Bug 476485 has been marked as a duplicate of this bug. ***
Comment 17 Rex Dieter 2008-12-15 07:53:38 EST
triaged (assigned).
Comment 18 Thomas Hartwig 2009-01-22 11:17:49 EST
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.
Comment 19 Rex Dieter 2009-01-22 11:53:58 EST
Per comment #10, if kcheckpass is crashing and is still reproducible please report upstream to bugs.kde.org.
Comment 20 Rex Dieter 2009-01-22 11:55:17 EST
Crash is occuring in kdebase-workspace, reassigning. 
(any additional thinkfinger-related help/insight/debugging advice welcome).
Comment 21 Douglas E. Warner 2009-01-22 12:12:26 EST
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.
Comment 22 Steven M. Parrish 2009-02-04 12:24:30 EST
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.
Comment 23 Steven M. Parrish 2009-04-27 14:19:46 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.