Bug 441144

added "debug" to pam-modules in  /etc/pam.d/common-auth:

Nov  3 17:40:31 linux kernel: input: Virtual pam_fp Keyboard as /devices/virtual/input/input13
Nov  3 17:40:31 linux kdm: :0[7812]: pam_fp(xdm:auth): Stored $HOME="/root".
Nov  3 17:40:31 linux kdm: :0[7812]: pam_fp(xdm:auth): Set $HOME="/home/christian".
Nov  3 17:40:31 linux kdm: :0[7812]: pam_fp(xdm:auth): Restoring $HOME="/root".
Nov  3 17:40:31 linux kdm: :0[7812]: pam_fp(xdm:auth): Starting pam_fp_prompt (pid 7812).
Nov  3 17:40:31 linux kdm: :0[7874]: pam_fp(xdm:auth): Starting pam_fp_swipe (pid 7874).
Nov  3 17:40:31 linux kdm: :0[7812]: pam_fp(xdm:auth): Password received, stopping child process (pid 7874).

No fingerswipe has occured.

Is kdm missing the ability for pam_fp? 

Same problem here with kdm and Beta4. Whereas the fingerprint reader works fine on the console login. 

here the same.. only disable fingerprinter reader and reboot helps.

*** Bug 443139 has been marked as a duplicate of this bug. ***

+1 from me. I accidentally created new bug, so report and info are in 
https://bugzilla.novell.com/show_bug.cgi?id=443139

*** Bug 442715 has been marked as a duplicate of this bug. ***

Dirk (thanks for taking the time!) just committed a bunch of patches to FACTORY.  This should be fixed therefore.

However, it needs some testing.  Christian, can you please test with FACTORY packages of kdebase4-workspace later this week?  Thanks.

Also, please check if the screensaver can be unlocked using the fingerprint reader.

I'll test this on another machine.

Are the fixes also for kdebase3-kdm?

To be discussed.

Done.

KDE 3.5 is unsupported with regard to SLE11.

Christian, if you want to get fingerprint reader support working with KDM3 on OS11.1, please help out.  There are patches available -- don't know where exactly -- maybe Dirk can tell more.  Those need just a few adoptions and then should work fine.

If KDE 3.5 is unsupported then I recommend that yast either switch automatically to KDE 4.x KDM or refuse to enable fingerprint reader support. I happily upgraded my notebook from 11.0 to 11.1 and didn't know that kde 3.5 didn't work with the fingerprint reader. (PS: I have DISPLAYMANAGER="kdm" in /etc/sysconfig/displaymanager.. What do I need to set this to to use the new version of kdm? kdm4?)

Tested kdm in Beta5, I can login with password, kdm does not freeze anymore.

The screensaver can not be unlocked by the fingerprint reader(In reply to comment #7 from Timo Hoenig)
> Dirk (thanks for taking the time!) just committed a bunch of patches to
> FACTORY.  This should be fixed therefore.
> 
> However, it needs some testing.  Christian, can you please test with FACTORY
> packages of kdebase4-workspace later this week?  Thanks.
> 
> Also, please check if the screensaver can be unlocked using the fingerprint
> reader.

The screensaver can not be unlocked using the fingerprint reader in Beta 5


> 
> I'll test this on another machine.
> 

I'm a little unsure if we're still discussing KDE3.5 or KDE4.

Anyway.

KDE4: kdm and screensaver should work
KDE3.5: kdm and screensaver should not work (unless someone work on integrating Dirk's patch)

Me too now, are the patched packages in Beta5?

I'm talking about the kdm from package kde4-kdm-4.1.3-5.1.

I've tried to unlock the screensaver in a kde4 session. 

Have you tested it already?

No, because (a) I don't have KDE4 installed and (b) don't have a fingerprint reader in my system :-)

the same problem with beta5 (kde4 64bit).. and now I can't disable the fingerprint plugin for this user, because the console yast ok button doesn't work.. :( so a normal user can't use this installation anymore.

tested kde4-kdm-4.1.3-7.1 from Factory. KDM still freezes after entering the password. Is the fix already checked in? 

Will it be fixed in RC1?


here some output from /var/log/messages:

Nov 20 18:08:52 schneemobil kernel: input: Virtual pam_fp Keyboard as /devices/virtual/input/input8
Nov 20 18:08:52 schneemobil kdm: :0[3329]: pam_fp(xdm:auth): Stored $HOME="/".
Nov 20 18:08:52 schneemobil kdm: :0[3329]: pam_fp(xdm:auth): Set $HOME="/home/christian".
Nov 20 18:08:53 schneemobil kdm: :0[3329]: pam_fp(xdm:auth): Restoring $HOME="/".
Nov 20 18:08:53 schneemobil kdm: :0[3329]: pam_fp(xdm:auth): Starting pam_fp_prompt (pid 3329).
Nov 20 18:08:53 schneemobil kdm: :0[3927]: pam_fp(xdm:auth): Starting pam_fp_swipe (pid 3927).
Nov 20 18:08:53 schneemobil kdm: :0[3927]: pam_fp(xdm:auth): Awaiting swipe (AuthenTec AES2501, right index).
Nov 20 18:08:53 schneemobil kdm: :0[3329]: pam_fp(xdm:auth): Password received, stopping child process (pid 3927).

After a small debug-session with Timo here some new facts.

/usr/share/kde4/config/kdm/kdmrc sets PluginsLogin to default, after setting it to generic the fingerprint reader works, kdm does not freeze, but the themes doesn't fit.

So the tested packages "worked", just the config has to be changed and a working theme is needed.




Here some output from 'rpm -i --force kde4-kdm-4.1.3-7.1.x86_64.rpm' :
Information: reading pre-existing kdmrc /usr/share/kde4/config/kdm/kdmrc (config version 2.4)
Warning: --old-kde does not end with /share/config. Might wreak havoc.

It is now impossible to unlock the screen in kde4.
If the screen is locked and you want to unlock it shows the message "unlock failed" (I've configured german so this is maybe not the right string).

These messages are in /var/log/messages:

Nov 24 13:27:48 schneemobil kcheckpass[5462]: pam_warn(xdm-generic:auth): function=[pam_sm_authenticate] service=[xdm-generic] terminal=[:0] user=[christian] ruser=[<unknown>] rhost=[<unknown>]
Nov 24 13:27:48 schneemobil kcheckpass[5462]: Authentication failure for christian (invoked by uid 1000)
Nov 24 13:27:51 schneemobil kcheckpass[5463]: pam_warn(xdm-generic:auth): function=[pam_sm_authenticate] service=[xdm-generic] terminal=[:0] user=[christian] ruser=[<unknown>] rhost=[<unknown>]
Nov 24 13:27:51 schneemobil kcheckpass[5463]: Authentication failure for christian (invoked by uid 1000)
Nov 24 13:27:54 schneemobil kcheckpass[5464]: pam_warn(xdm-generic:auth): function=[pam_sm_authenticate] service=[xdm-generic] terminal=[:0] user=[christian] ruser=[<unknown>] rhost=[<unknown>]
Nov 24 13:27:54 schneemobil kcheckpass[5464]: Authentication failure for christian (invoked by uid 1000)
Nov 24 13:27:57 schneemobil kcheckpass[5465]: pam_warn(xdm-generic:auth): function=[pam_sm_authenticate] service=[xdm-generic] terminal=[:0] user=[christian] ruser=[<unknown>] rhost=[<unknown>]
Nov 24 13:27:57 schneemobil kcheckpass[5465]: Authentication failure for christian (invoked by uid 1000)

Is here something missing like the problem with the missing theme?

Regarding KDE3: both KDM3 and kscreensaver3 support and work with fp-readers. At least it works for me with pam_fprint (AuthenTec AES2501 USB scanner found on HP laptops). The way it is implemented in KDE3 (and maybe in KDE4 as well) is a bit funny. Actually in order to authorize with fp, user needs to choose login name and press <enter> on empty password field at kdm login screen, or press <enter> after kscreensaver prompts for password to unlock. After <enter> is pressed popup appears offering to scan <enrolled finger> on scanner. Pressing <OK> button of this popup before actual finger scan leads to some sort of kdm/kscreensaver lockup, but this means that fp-scanner is waiting for finger image input. Just scanning finger afterwards (if successfull) leads to session unlock. But whenever i enter correct password first, and press <enter>, i still get finger scan request popup, that should not happen with correct password entered. So, kde3/4 fingerperint support bugs are as follows:

1. if PAM is set to support fingerprint scans, kdm/kscreensaver should offer this auth type to user immediately, without waiting for user to press <enter>, with no UI lockups;
2. if finger scan is successfull, kdm/kscreensaver should log in/unlock immediately without any unnecessary keypresses;
3. if correct password is entered and <enter> pressed without any finger scan, kdm/kscreensaver should accept this and log in;
4. if INCORRECT password is entered, kdm/kscreensaver should not wait for finger scan, but fail this attempt like it does now with wrong password entered and no fp enabled.

I will try to create mockups for kdm and screensaver and attach them later here.

Just a note:  we're using pam_fp not pam_fprint on our products as it allows concurrent authentication (either swipe or password).

Created attachment 255566 [details]
kscreensaver unlock dialog mockup

This is mockup for kscreensaver unlock dialog, something similar is needed for KDM as well.

Timo, i see the difference now. I just changed to it from pam_fprint and did some tests. Anyway, even with it, i still require to hit <enter> on empty password field before doing finger scan (at least in kscreensaver).

Alexander, right, I just wanted to clarify that pam_fp is used.  That shouldn't change much of you analysis.

However, as far as I know, there's the "classic" greeter which should be used in conjunction with fingerprint readers.  It changes the the behavior.  In case of kdm:

User selects user - hit enter - (new dialog) - prompt for password or swipe finger

In case of screensaver:

(user already determined) prompt for password or swipe finger

However, even if selecting the classic greeter, things seem not to work properly.  Unfortunately I'm no KDE expert and can not help much.

Just tested both KDM3 and KDM4, and KDE3 & KDE4 sessions, with kscreensaver3 and kscreensaver4. Both KDE3 and KDE4 work exactly the same:

a) KDM
1-i. i choose user with finger enrolled
2a-i. enter correct password and hit <enter>; GOTO #4
2b-i. hit <enter> in empty 'password' field, kdm freezes; GOTO #3
3-i. swipe enrolled finger
4-i. session starts immediately with no further keypresses

1-ii. i choose user without finger enrolled
2a-ii. enter correct password and hit <enter>; GOTO #3
2b-ii. hit <enter> in empty 'password' field, kdm says 'wrong pass'
3-ii. session starts immediately with no further keypresses

b) kscreensaver: X-i - user with finger enrolled, X-ii - user without finger enrolled
1-i. i press any key to trigger unlock dialog
2a-i. enter correct password and hit <enter>; GOTO #4
2b-i. hit <enter> in empty 'password' field, dialog freezes; GOTO #3
3-i. swipe enrolled finger
4-i. session unlocks immediately with no further keypresses

1-ii. i press any key to trigger unlock dialog
2a-ii. enter correct password and hit <enter>; GOTO #3
2b-ii. hit <enter> in empty 'password' field, kscreensaver says 'wrong pass'
3-ii. session unlocks immediately with no further keypresses

Tested console as well:

Login: alex<enter>
Password or swipe finger:

whenever i enter correct password, i enter shell; if i swipe finger successfully, i enter shell immediately, without pressing <enter>. Whenever i swipe wrong or enter wrong pass, i get 'incorrect user name' and Login: prompt again. This behaviour is perfect.

Login: root<enter>
Password:

User without finger enrolled behaves like no FP auth is enabled - perfect.

----------------
Bottomline
----------------
KDM/kscreensaver should behave like console 'login'.

Whenever i choose user with finger enrolled in KDM, greeter should adjust widgets and provide some spacer with info as in mockup i posted earlier. If kscreensaver is running on session with finger enrolled, it should provide dialog similar to my mockup.

Both should accept swipes without any <enter> presses OR passwords ended with <enter> keypress and without UI lockups, like it is done in console.

i use the following components:
KDE 3.5.10 release 21.7
kdeartwork3-xscreensaver-3.5.10-1.50.x86_64
KDE 4.1.73
kde4-kdm-4.1.73-3.3.x86_64
kdeartwork4-screensaver-4.1.73-1.6.x86_64
libfprint0-0.0.6-11.1.x86_64
libfprint0-32bit-0.0.6-8.11.x86_64
pam_fp-0.1-10.11.x86_64
pam_fp-32bit-0.1-10.11.x86_64

KDE4 installed from http://download.opensuse.org/repositories/KDE:/KDE4:/UNSTABLE:/
libfprint installed from
http://ftp5.gwdg.de/pub/opensuse/repositories/home%3a/dgege%3a/fprint/openSUSE_Factory

I'm not sure this bug has the right severity?!

A user can't use the system after enable finger print reader! And disable finger print reader for this user (with yast console) doesn't work! :(

It still happened to me with the release version. I had to uninstall the pam_fp package to work around the problem.

I tested several scenarios: 
1) login through kdm feezes, but login in text mode (init 3) and 'startx' works perfectly.
2) logout from this perfectly running Xorg session freezes.
3) a kill of Xorg (2xCtrl+Alt+Bksp) also freezes.

So I think the problem is not with kdm, but with the stopping of Xorg. Starting Xorg is not a problem, so I get the kdm login screen and I can "startx". But from the login screen to the user Xorg session, IIRC, Xorg is stopped and restarted and it is during stopping that it fails.

I have an x60 tablet and I thought it was related with the tablet features, but I disabled all the tablet entries in xorg.conf and the problem persisted. Also in safe mode the killing of Xorg hangs. I am attaching Xorg.0.log and kdm.log 

Created attachment 263084 [details]
Xorg.0.log from a failed login session

Created attachment 263085 [details]
kdm.log from a failed login session

*** Bug 463202 has been marked as a duplicate of this bug. ***

hmh I was wondering because this bug has a SHIP_STOPPER flag..

Created attachment 263921 [details]
Updated pam_fp.c to make kdm etc work with pam_fp

I managed to get kdm/kdesktop_lock to work as described by Alexander Lavrinenko in comment #26, but only after hacking the pam_fp source code. I am using the opensuse 11.1 release version: kde4-kdm-4.1.3-10.1, pam_fp-0.1-11.5, libfprint0-0.0.6-8.16, libfprint-devel-0.0.6-8.16
I am not 100% sure what happens but two changes in pam_fp.c are necessary to make it work:

1) In the original code in function pam_fp_prompt() there is a wait(NULL) statement which is the one that hangs. Changing it into
waitpid((pid_t)-1,&stat_loc,WNOHANG) stops it from hanging after a password is entered. Somehow, the child, which is basically pam_fp_swipe(), doesn't respond. It doesn't seem to be a problem if wait doesn't hang (so WNOHANG) but it needs to be figured out why the child doesn't respond. I have a feeling it has to do with kdm_greet which is suspended when pam_fp is active. The child itself does disappear so there is not a real problem this way...

2) In the reclaim loop it is necessary to first deinit pam_fp, using the pam_fp_libfprint_deinit function, otherwise the device is still in use and it will give a fp_dev_open() failed error if we need to swipe again after a mis-swipe. I have changed deinit slightly to prevent double free()'s or close()'s.

Mischa, thanks for looking into this.

Re 1)  I can't recall the exact reason, but there was a specific one why I decided to use wait(NULL).  Probably I had to deal with zombies in case of not using it.  IIRC that only applied when logging in using the password which causes the child to be killed.

Re 2)  Nice catch.  I didn't yet check the source yet but I will do when I return from vacation (next week)

Mischa, would you mind to attach a diff of all of your changes?  I have reserved some time to look into this in the next days.

Created attachment 266122 [details]
patch for pam_fp.c, unified diff

Hi Timo,
here's the patch, all changes are in pam_fp.c. Just let me know if you need more info. A few changes are to add more debug info.
Best regards,

Mischa

Mischa, thanks for the quick reply and for the patch, of course.

Did you check whether you see zombie processes due to the wait/waitpid change?

IIRC zombies occurred whenever pam_fp was enabled and the login was done using a password rather than with the fingerprint.  I think I could easily reproduce this with console logins.

(In reply to comment #38)
> Mischa, thanks for the quick reply and for the patch, of course.
> 
> Did you check whether you see zombie processes due to the wait/waitpid change?
> 
> IIRC zombies occurred whenever pam_fp was enabled and the login was done using
> a password rather than with the fingerprint.  I think I could easily reproduce
> this with console logins.

Hi Timo,

yes, I did check zombie processes and they aren't there for my patched pam_fp. Not for console login, not for kdm, not for kdesktop_lock. I tried with fingerprint, with password and with fingerprint after an enter and in all cases no zombies appeared, also not after repeated logins.

In the meantime I have some idea of where the problem lies: when kdm is waiting for a fingerprint the process tree is as follows:
    0  3291     1 Ss   /usr/bin/kdm
    0 21615  3291 SLs+  \_ /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/lib/xdm/authdir/authfiles/
    0 21622  3291 S     \_ -:0
    0 21623 21622 Sl        \_ /usr/lib64/kde4/libexec/kdm_greet
    0 21663 21622 S         \_ -:0

Looking at /var/log/messages:
    Jan 20 12:13:44 woembie-l kdm: :0[21622]: pam_fp(xdm:auth): Starting pam_fp_prompt (pid 21622).
    Jan 20 12:13:44 woembie-l kdm: :0[21663]: pam_fp(xdm:auth): Starting pam_fp_swipe (pid 21663).
    Jan 20 12:13:44 woembie-l kdm: :0[21663]: pam_fp(xdm:auth): Awaiting swipe (UPEK TouchStrip, right index).

i.e. pam_fp_prompt runs as part of 21622 (it's a module so it doesn't run as a standalone process), while 21663 is the pam_fp_swipe. Note however that kdm_greet ALSO runs as child of process 21622, therefore, if pam_fp_prompt is waiting for all its children, like it is when using wait(), it doesn't only wait for pam_fp_swipe, but also waits for kdm_greet. I am not sure why kdm_greet is not responding (it doesn't need to, but would be nice anyhow), it does seem to freeze while waiting for a swipe, for example the screen is not updated. It is a bit strange, because ps doesn't seem to indicate that any of its threads is suspended...
I don't have much time to try it now, but I would think that if the wait() would only wait for the proper child pam_fp_swipe (you again need waitpid for that), it should work. Keep me informed...

Best wishes,

    Mischa

Created attachment 267710 [details]
Mischa's patch, updated + changes required to fix bug 463557

Mischa,

I've applied your changes and it seems to work find.  Thanks for your time looking into it.  Much appreciated.

While testing the reclaim code it crashed several times which made me add more code to the deinit function.

Also, I've added some reset function (cf. bug 463557).  This requires a new libfrpint which I'll build next.  I'll post links to the rpms as soon as I'm done.

May I ask you to test this with kdm?  That would save me a bit of time as I don't have a system prepared for that.

After the sync cronjob has kicked in they will be available at:

* http://beta.suse.com/private/thoenig/FACTORY

and

* http://beta.suse.com/private/thoenig/openSUSE-11.1

Mischa et al.: please let me know if those packages solve the issue.

Thanks!

Submitted to SLE11 and FACTORY.  Leaving this bug open, waiting for Mischa's answer.

This should be provided as an online update for OS11.1

(In reply to comment #43)
> Submitted to SLE11 and FACTORY.  Leaving this bug open, waiting for Mischa's
> answer.
> 
> This should be provided as an online update for OS11.1

Hi Timo,

Thanks for the work. I'm currently on holiday (without laptop), I'll be back Feb 16th and will then look into it as soon as possible, my apologies for the delay...
By the way, what type of crashes did you get?
 
Best wishes,

     Mischa

Mischa, that's alright, no worries because of the delay.  Enjoy your holidays :)

Regarding the crashes:  As fprint->data and fprint->dev were not set to NULL in the struct after freeing/closing a recurring call to pam_fp_libfprint_deinit caused crashes for me while testing the code for surprise removal of the USB device.  But those crashes are history as I now set them to NULL.

(In reply to comment #45)
> Mischa, that's alright, no worries because of the delay.  Enjoy your holidays
> :)
> 
> Regarding the crashes:  As fprint->data and fprint->dev were not set to NULL in
> the struct after freeing/closing a recurring call to pam_fp_libfprint_deinit
> caused crashes for me while testing the code for surprise removal of the USB
> device.  But those crashes are history as I now set them to NULL.

Hi,
I have enjoyed them (-;
Your version works fine, no error messages and I agree that the two pointers need to be set to NULL. I wonder why I didn't have problems with that... What exactly do you mean with a surprise removal of the USB device?

Mischa

Just do the following (root needs to have a fingerprint available):

Terminal 1:

$ su -

(don't swipe, don't type a password

Terminal 2:

$ modprobe -r uhci-hcd ; sleep 3 ; modprobe uhci-hcd ;

Terminal 1:

Now swipe the finger or type a password.

While this sounds like a weird use case, it's total valid as it is similar to what happens if a system is being suspended (the USB device will drop of the USB bus on suspend, and will reappear when resuming).

Anja, I'd like to release the fix for this issue as online update for 11.1.  Can you please provide a SWAMP id?  Thank you.

*** Bug 450893 has been marked as a duplicate of this bug. ***

ping..

Patchinfo submitted, pam_fp submitted to 11.1.

Closing as FIXED.

patchinfo restarted.