Version: (using KDE KDE 3.4.0) Installed from: Compiled From Sources OS: Linux Hello, PAM can report back to the application a user id to be used in forther processing. For most cases, KDM try to getpwnam with the string the user entered. As I understand the KDM should always fetch user id from PAM after authenticate, so KDM will receive the user authenticated by the PAM module. This will allow smartcard login using PIN only, and will allow the use of PAM module that maps logic names into physical account. The code exists, but currently active only if curuser=NULL. I could not find a situation when curuser=NULL, but I am sure it have a reason. I suggest to activate it for all request, worse case scenario the same id that was provided to PAM would be returned. I've checked it using password and smartcard and it seems to work correctly. --- kdm/backend/client.c.old 2005-05-14 00:43:58.000000000 +0300 +++ kdm/backend/client.c 2005-05-14 00:40:08.000000000 +0300 @@ -344,7 +344,12 @@ doPAMAuth( const char *psrv, struct pam_ Debug( " pam_authenticate() returned: %s\n", pam_strerror( pamh, pretc ) ); if (pdata->abort) return 0; - if (!curuser) { + + /* + @ALON + Always ask PAM for user + */ + /*if (!curuser)*/ { Debug( " asking PAM for user ...\n" ); pam_get_item( pamh, PAM_USER, &pitem ); ReInitErrorLog(); ---------------------------------------------------------------------------- If we at it... In the long term, maybe the logon dialog should be modified to display PAM prompts... So that biometric, smartcard PAMs can be integrated and communicate with user. Best Regards, Alon Bar-Lev.
Created attachment 11032 [details] Diff - allow PAM to set the user id
the zero-check was supposed to be exactly for your case: if no user was entered, the backend knows no name and will ask pam. mind finding out why it does not work that way? > If we at it... > bug #47971
I think the curuser should be compared to an empty string. But it is still not a good PAM practice (As I understand), the userid should be taken from PAM. For example... A PAM can be written to map full name users to short name... "Alon Bar-Lev" -> so1234 Current implementation does not allow this. I think that you should always get the user id from PAM after authentication.
It uses two or more jobs in order to compile. "make -j2" I think something in the dependecy is not complete... So it chooses to compile something before its dependencies ready.
Please disregard last comment. Wrong post.
guessing doesn't help; i can do this myself. ;) it's that way for a reason: if you choose the "classic" method, you are saying that you use unixuser+passwd auth. we need this special case for password-less and automatic logins to work. question is only, why your setup does not fail in a more spectacular way, like a segfault (i.e., what makes curuser be non-null).
I've checked. It is an empty string. I could not see when curuser is set to NULL in client.c. But still I think you should get the user from PAM. And I don't agree that if you choose "classic" method with PAM enabled in configuration you say you use unixuser+password. You say you use pamid+password. Best Regards, Alon Bar-Lev.
> I could not see when curuser is set to NULL in client.c. > it's done in session.c > You say you use pamid+password. > no. there is no universal way to obtain a list of users for this and consequently no way to configure it graphically. therefore it must be based on unix names. apart from that, the name "classic" says something about the intentions. ;) so the solution is once again writing a proper conversation plugin. base it off of the classic one. either cut it down to make no assumptions about the meaning of the userid lineedit, or trim it to the functions of the particular pam module.
I don't understand. Why getting the PAM userid from PAM after authentication does not meet your definition? If PAM does not change the userid it works. If PAM does change the userid it works. So it is win-win situation. And with simple modification... That allows user to enter "pamid" and kde to get "unixuser", where on most systems: "pamid"="unixuser". Even with "classic"... Can you find a sequence that worked so far that fails after my suggested modification? If you can, can you please explain it to me?
Hello Oswald I've read client.c and classic plugin again and again. I still don't understand how a custom plugin can implement a complete PAM authentication, since all PAM logic is located in client.c which is common to all plugins. As result kdm will never get correct userid, since it never asks PAM, unless you want me to use the edge condition of curuser=NULL, The plugin should set curuser to NULL in order to signal client.c to ask the userid from PAM. Although I am waiting for your response to the previous post, I think that at the least the condition can be changed to: - if (!curuser) { + if (!curuser || !curuser[0]) { So that the PAM query will happen if the user enters an empty user name. In order to perform a complete authentication logic in plugin, the plugin should be allowed to process all authentication process and return userid, so that the code of client.c should be divided into several plugins: PAM, Kerberos, Linux etc... Then I will be able to implement a PAM plugin which shows PAM prompts, wait for user response, on TAB/Enter sends the user response, display PAM ports and so on... This way a generic plugin will be able to replace the classic one. But I don't understand how it can be implemented with current plugin interface. Regardless, I still think that you should always get userid from PAM after authentication - if you use PAM to authenticate. Best Regards, Alon Bar-Lev.
if the conversation plugin says it has set a unixusername, then the backend can rely on it (otherwise the password-less login stuff would operate on data it should not operate on). if it does not, curuser is null. look at conv_interact() in session.c.
Hello Oswald, I cannot say I understand how exactly the plugin can do this, in order to do that I need to go over all the code. But can you please consider answering my question from last post: -------------------------------------------------------------------------- Why getting the PAM userid from PAM after authentication does not meet your definition? If PAM does not change the userid it works. If PAM does change the userid it works. So it is win-win situation. And with simple modification... That allows user to enter "pamid" and kde to get "unixuser", where on most systems: "pamid"="unixuser". Even with "classic"... Can you find a sequence that worked so far that fails after my suggested modification? If you can, can you please explain it to me?
> I cannot say I understand how exactly the plugin can do this, > the entire plugin interface is declared in kdebase/kdmlib/kgreeterplugin.h. you're looking for IsUser. > But can you please consider answering my question from last post: > i did, you just did not understand the answer. ;)
It is true... I don't understand... You claim that auto completion will not work... But I claim that it will... It will list Linux users, but if the user entered (MANUALLY) a different user which is not on the list it will work too. Since in 95% of the time "Linux user"="pam user" and 5% users will not use the auto completion. But OK... you don't like PAM... I've studied your discussion of bug 47971. Can you please comment regarding the following change? - if (!curuser) { + if (!curuser || !curuser[0]) { So that empty user name will acquire PAM id?
> You claim that auto completion will not work... > i certainly never said that. but apart from that, you are right ;): it will not work, because it will not work consistently. we don't want inconsistent behavior. > Can you please comment regarding the following change? > > - if (!curuser) { > + if (!curuser || !curuser[0]) { > it's pointless. under correct circumstances the "empty string" case will never occur (unless the user enters no id at all, but this is something different).
>> Can you please comment regarding the following change? >> >> - if (!curuser) { >> + if (!curuser || !curuser[0]) { >> >it's pointless. under correct circumstances the "empty string" case will never >occur (unless the user enters no id at all, but this is something different). It is NOT pointless, since if you work with smartcard or biometric, you just leave the user empty and on password you fillin the PIN. PAM then determind which user it is. So this change is the minimum required for working. I've performed this change, and it works for user/password and smartcard... BTW: My initial modification also works.... It works in all your scenarios and mine! But I guess you won't reconsider to get linux user from PAM... I still don't understand why... Although you claim that you explained it to me, I don't think that you did, and I will be happy if you try.
you still don't get the idea behind the plugin concept. if you have a pam setup that falls back to smartcard if the entered user name was empty, then you should be using a plugin that knows this and sends the proper information to the backend (which sends it to pam). this plugin can present a more intuitive prompt than "username:" when it means "unixusername or empty for smartcard authentication". it can automatically monitor the smartcard reader for activity to switch to a proper pin input view. everything else is a hack, both from the technical and the usability pov. apart from that i won't blur the barrier between "entities" (whatever items the plugin might pass to pam) and "users". there is one strictly defined way to cross it: passing the IsUser flag to the backend by plugins that _know_ that they are dealing with unixusernames. anything else is a potential security hole in conjunction with the no-password features.
Dear Oswald, Thank you for explaining this. I though that we can provide a simple solution for a simple problem. I thought that I can convince you that if you use PAM to authenticate the right approach will be to get the Linux user from PAM. Had I convinced you that, we would have solved the whole problem. This is how all other environments I've checked work. Moreover, I've done this change in your code, and found that no functionality was lost after this change. From my point of view you failed to provide a good explanation why you don't wish to do so. It will work in all sequences you presented. On the contrary... In failing to query PAM for Linux user CURRENTLY you OPEN a security hole... Since PAM can authenticate Linux user X and you continue to use user Y, since kdm is not aware of the change. I suggest you check other PAM client implementation and see that all query Linux user after authentication. Since I failed to convince you that this is the right way to go, I've tried to handle the smartcard edge condition like you handled all your edge conditions in your client.c code... ...if (!strcmp (..., "classic"))... Since providing a special plugin is unnecessary... The PKCS#11 PAM knows how to integrate itself in user/password environment and is working with all other environments I've checked, But then I failed again... I agree with you... adding a new edge condition to the already complex client.c is not wise. I just want to note that I get the plugin concept... As strange as it may be read... :) BUT if it was so good and simple I am sure your implementation of PAM, Kerberos, Linux etc... were implemented as plugins... Rather as compilation configuration... Since you choose not to do so, I don't think you should ask others to do so. This is true for as long as you have current "FAT" client.c implementation and have so many edge conditions coded into the source asking which plugin was selected. Can you please reconsider my argument regarding ALWAYS take the Linux user from PAM after successfully PAM authentication? I think this is the correct solution. Please read the following quotes: From (http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_appl-3.html) >3.1 What can be expected by the application > PAM_USER > The username of the entity under who's identity service will be given. That > is, following authentication, PAM_USER identifies the local entity that gets > to use the service. Note, this value can be mapped from something (eg., > "anonymous") to something else (eg. "guest119") by any module in the PAM > stack. As such an application should consult the value of PAM_USER after each > call to a pam_*() function. From (http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_appl-4.html) > 4.4 The identity of the user > The Linux-PAM modules will need to determine the identity of the user who > requests a service, and the identity of the user who grants the service. These > two users will seldom be the same. Indeed there is generally a third user > identity to be considered, the new (assumed) identity of the user once the > service is granted. > The need for keeping tabs on these identities is clearly an issue of security. > One convention that is actively used by some modules is that the identity of > the user requesting a service should be the current uid (userid) of the > running process; the identity of the privilege granting user is the euid > (effective userid) of the running process; the identity of the user, under > whose name the service will be executed, is given by the contents of the > PAM_USER pam_get_item(3). Note, modules can change the values of PAM_USER and > PAM_RUSER during any of the pam_*() library calls. For this reason, the > application should take care to use the pam_get_item() every time it wishes to > establish who the authenticated user is (or will currently be). Best Regards, Alon Bar-Lev
> In failing to query PAM for Linux user CURRENTLY you OPEN a security hole... > Since PAM can authenticate Linux user X and you continue to use user Y, since kdm is not aware of the change. > ARGH! you _still_ didn't get it! if curuser is non-zero, then it _is_ the correct unix user. that's the way i defined the interface. if you abuse the "classic" method, it's your own fault. > BUT if it was so good and simple I am sure your implementation of PAM, Kerberos, Linux etc... were implemented as plugins... > nonsense. i would just be duplicating pam. the conversation plugins are not a replacement for pam, but a complement. you needn't to quote the manuals, i have read them three times. you know what conclusions i drew. you also needn't to tell me how other clients handle things, i read other sources often enough. they are just trying to make the best of the situation with as little effort as possible. i've chosen the hard way, because i like things being done *right*.
OK. Let's leave this discussion. I think your *right* is *wrong*. I think you violating well defined and written PAM requirements. And if you had chosen to do things in the hard way, you would have used the plugin model your-self, so my modification would have been just copy your plugin alter PAM behavior without any change to kdm it-self. After this discussion, I am sure my modification to client.c is correct and this solution is the one I will implement. Best Regards, Alon Bar-Lev.
> I think you violating well defined and written PAM requirements. > nonsense. i defined a mode with _additional_ _restrictions_ and called it "classic". because of the assumptions it allows for, certain features could be added (password-less & automatic login). because users want these features, this mode is the default. and for 99% of the cases it is sufficient. now you come with special requirements. pam was written with those in mind, but the concept does not cover all aspects of the problem, and even what is there is far from being perfect. so i developed an architecture to a) work around the shortcomings in a generic way and b) to cover the missing aspects (e.g., guis that really fit the authentication methods used). i think i succeeded, because your requirements can be fulfilled without changing one bit of the kdm binary, by a skilled programmer prolly in less time than we spent on this discussion. and yes, one day i'll write a "generic" plugin that is just as "useful" as gdm's conversation function ...
Created attachment 18041 [details] kdm-3.5.4-pam.patch
*** Bug 182623 has been marked as a duplicate of this bug. ***
fwiw, the generic plugin exists since kde 4.1 or so. however, due to architectural limitations, kdm will fail to offer some functionality when a pam module actually waits for user input without using prompt callbacks (be it standard textual or linux-pam specific binary prompts). therefore the feature is inofficial as yet. use at your own peril - PluginsLogin=generic
This thread is more than 3 years old! This was the reason I had opened a new one #182623. The only relevant question here is: WHEN will kdm and kscreensaver make proper use of PAM in their stable release? If the answer is "never", then the whole kde system will _never_ be able to make use of alternate PAM authentication methods like biometric authentication, usb token, smart cards etc. I guess: Neither are developers of PAM modules ready to develop unnecessary special plugins for kdm / kscreensaver, nor are the users willing to apply (4 years old) patches on their systems, in order to be able to make use of these technologies.
*** Bug 183643 has been marked as a duplicate of this bug. ***
adjusting title to cover the entire scope of the problem.
I too would like to see some sort of resolution to this issue. I use FingerprintGUI (by Wolfgang Ullrich, posting above), and have been forced to use Gnome in order to make my fingerprint scanner work, because I don't have enough working knowledge to explore and make it work with KDE.
Wow - interesting to read this bugreport. I just wanted to add, that I also like to see a easy possibility to add full PAM-support to KDM. I think the only use of PAM is, that there is one central piece which handles all the different ID-modes - why also have KDM to care about it? If pwd-less login is needed, wouldnt it be possible to implement it with PAM? Would really like to get my fingerprint-reader to work. Configuring it for su/sudo/gdm/... was just as it should be. Define one pam-auth routine and enable it for the different services. And all works. Nothing to tune within the services them self.
please add full PAM-support to KDM
My English is not very good. Excuse me if I said something wrong. As I see - this problem has remained unsolved. I found solution for using fingerprint-gui PAM module for authorization in kde4, with kdm. I examined the kdm source code, and has made changes, that is necessary to properly operate with this module. Now is able to login to kde4 session using fingerprint-gui, no pressing keys or username entering needed. Just swipe finger - and login will be performed with username, of which one fingerprint recognized. Classic login/password method is remains possible together with fingerprint method. The user can use any convenient method. Patch will be posted below as attachment. I'm not good in programming in Qt, so I could be mistaken with a right way. But with my changes all works nicely.
Created attachment 57579 [details] patch for fingerprint-gui (kdm-4.6.0) There is a patch for using kdm with fingerprint-gui module. For version 4.6.0
the patch is completely wrong. to have things "just work" for both fingerprint and regular login, just use the generic greeter plugin (see comment 24). note that it doesn't work particularly well with the themed greeter if the theme sucks (i.e., with kde's current default theme). suse tried to hack around this (and some other distros picked up the patches), but they are just making things even worse. what is still missing is multi-processing in the backend so it could start a shutdown authorization while the login authorization hangs in PAM, or to be able to start two concurrent login authorizations (think fingerprint and password) (note that there is no gui for the latter yet; see bug 232011).
(In reply to comment #33) > the patch is completely wrong. > to have things "just work" for both fingerprint and regular login, just use the > generic greeter plugin (see comment 24). note that it doesn't work particularly > well with the themed greeter if the theme sucks (i.e., with kde's current > default theme). suse tried to hack around this (and some other distros picked > up the patches), but they are just making things even worse. > what is still missing is multi-processing in the backend so it could start a > shutdown authorization while the login authorization hangs in PAM, or to be > able to start two concurrent login authorizations (think fingerprint and > password) (note that there is no gui for the latter yet; see bug 232011). Maybe my patch is wrong. But it works! I don't have much experience as you are, and I did it as I could. Almost six years this problem remains unsolved. After all it's much better than just talking about what needs to be done. Maybe people who have more experience, on the basis of this patch make it more correctly, I don't know. But whoever wants to use fingerprint-gui, can do so even right now, because the wait until someone will do it correctly, could take another six years. In any case, thanks for attention.
> the patch is completely wrong. > to have things "just work" for both fingerprint and regular login, just > use the > generic greeter plugin (see comment 24). note that it doesn't work > particularly > well with the themed greeter if the theme sucks (i.e., with kde's current > default theme). suse tried to hack around this (and some other distros > picked > up the patches), but they are just making things even worse. > what is still missing is multi-processing in the backend so it could start > a > shutdown authorization while the login authorization hangs in PAM, or to > be > able to start two concurrent login authorizations (think fingerprint and > password) (note that there is no gui for the latter yet; see bug 232011). Did you try to use it? I successfully using patched kdm. With classic theme. At least, this theme is set as default in gentoo distribution. And I did this patch for myself by first. Because I can't find any other way to use fingerprint reader for kde authorization, except using gdm for login to kde session. But why I should use gdm if I not GNOME user? Sorry, my english is not good for good discussion, maybe I mistaken somewhere. I just want to help the people wants using fingerprint-gui. Best regards, Alexey Prokopchuk.
@Alexey: thanks a lot for your patch!! (did not test it yet though) @Oswald: maybe Alexey's patch is wrong, but could you please care to explain him/all why? Your answer is quite rude :-( Maybe the "plugin" you mention in Comment #24 is great but you didn't tell even a single line what/how to do to use it.
Yes, the generic plugin works with fingerprint-gui, I have it checked out. But I tried to find a solution about a month and found nothing. With my english this is not an easy task, moreover, nowhere in the KDM documentation I could not find no one word about the generic plugin. And in Changelog and README from kdm package too. It's so secret plugin that his description could not be added to documentation and changelog which starts from 1997? For a person with my level of English is very difficult to notice and understand your fleeting mention about this plugin. Anyway, the solution to the generic plug-in - a halfway solution. Perhaps that is what I am about to say will be misunderstood. About the way with generic plugin I'd say it's like to drive on the luxurious car and pedaling like on a bike. Something like that. And I'm very surprised that the developers of such a popular product in all respects, did not find a more elegant solution for such a long time . If developers were made even some steps in this direction, the layman like me would not be taken for the solution of such complex problems.
glad to hear it works for you. i agree that the whole thing is totally underdocumented - and that's intentional, because of this very bug report (i.e., it's not ready). anyway, what's wrong with the generic plugin? how is it different from what you hacked up?
I think so, because not everything works as it should with generic plugin. For example, in the case with kscreensaver user must guess about an alternative method of authentication is available, because no visual warnings about the possibility of authentication by fingerprint there. And anyway, since laptops with fingerprint scanners have become very common, there is need to do some standard way to use them to log in to KDE. In order to no one tried to hack the existing code to make this possible. Maybe, I'll try to do a plugin for kdm, but for now I almost completely not familiar with Qt, unfortunately. I would very much like to embed this capability in kdm.
hmm, i thought i had fixed the screensaver's auto-configuration (somewhat). i'll have a look. there is already a specialized fingerprint plugin: http://lists-archives.org/kde-devel/22984-try-fingerprint-login-using-kdm.html if you want to do something useful (other than implementing multi-processing in the backend, which is *quite* a challenge), you could write a GUI for configuring greeter plugins. but it must come with a big fat warning until the multi-processing is done.
I tried to use the modules from your link. Very interesting, from this point can be start working on fingerprint readers support in KDE. But now these modules are almost useless, in comparison with fingerprint-gui they are losing. At least because these modules are still required to choose a user name, so pressing keys during authentication is required too. fingerprint-gui PAM-module with generic kdm plugin does not need any keyboard/mouse operations during authentication, just swipe finger. And now it's better way to using fingerprint readers with kde at all, I think. But these modules (from above post link) is a very good template to start building more seriously support of the discussed authentication method.
KDE. 2012. Fingerprint auth does not work out-of-the-box with a small nice GUI. RIDICULOUS JOKE. Shame on you.
Fingerprint reader works in kubuntu, how nice - but not in KDE. When I saw it is a bug, I thought it might be fixed soon, or maybe it is already fixed. But no, after seven years it is not fixed - so I guess it never will be. I don't get it.
<sarcasm> Perhaps Kubuntu used the completely wrong patch posted by Alexey ;-P </sarcasm> Sorry, couldn't resist ;-)
In new KDE versions since at least 4.8 kdm generic plugin can't longer be used as alternative authenticated method. I don't know what exactly was changed, have no time for it, unfortunately. But I seem to find where there may be a reason. Here is kdm-4.9.3 log: Nov 18 14:02:24 book fingerprint-helper[3168]: book fingerprint-helper[3168]: Message: Identified: alexpro (Right Middle) Nov 18 14:02:24 book fingerprint-helper[3168]: Have index 1 (user: alexpro). Nov 18 14:02:24 book fingerprint-helper[3168]: Waiting... Nov 18 14:02:24 book fingerprint-helper[3168]: ExitPrompt Nov 18 14:02:24 book fingerprint-helper[3168]: Display=:0 Nov 18 14:02:24 book fingerprint-helper[3168]: Using libfakekey to exit PAM conversation. Nov 18 14:02:24 book kdm_greet[3160]: greet_generic: gplugChanged() Nov 18 14:02:24 book kdm_greet[3160]: greet_generic->next() Nov 18 14:02:24 book kdm_greet[3160]: greet_generic: gplugChanged() Nov 18 14:02:24 book kdm_greet[3160]: greet_generic: gplugReturnText("", 0) Nov 18 14:02:24 book kdm: :0[3159]: PAM_conv success Nov 18 14:02:24 book kdm: :0[3159]: Invalid username on input, returned: ^A Nov 18 14:02:24 book kdm: :0[3159]: First char: 0x1 Last two lines says that after libfakekey presses "virtual Enter" and gplugReturnText("", 0), actually returns dirty buffer with first symbol 0x1. Same kdm behavior in kde-4.8 too. Now I forced to use kdm-4.6.3 because it works fine. There is log: Nov 18 21:51:33 book fingerprint-helper[14925]: Message: Identified: alexpro (Right Middle) Nov 18 21:51:33 book fingerprint-helper[14925]: Have index 1 (user: alexpro). Nov 18 21:51:33 book fingerprint-helper[14925]: Using libfakekey to exit PAM conversation. Nov 18 21:51:33 book kdm_greet[14917]: greet_generic: gplugChanged() Nov 18 21:51:33 book kdm_greet[14917]: greet_generic->next() Nov 18 21:51:33 book kdm_greet[14917]: greet_generic: gplugChanged() Nov 18 21:51:33 book kdm_greet[14917]: greet_generic: gplugReturnText("", 0) Nov 18 21:51:33 book kdm: :0[14916]: PAM_conv success Nov 18 21:51:33 book pam_fingerprint-gui[14916]: Prompting username returned PAM_SUCCESS. Nov 18 21:51:33 book pam_fingerprint-gui[14916]: Got username "alexpro" from pipe. Nov 18 21:51:33 book pam_fingerprint-gui[14916]: Have username: alexpro. Why now generic kdm plugin is broken? It's planned new feature or or someone's unfortunate mistake? It is hoped that this is still a mistake... Finally, almost eight years passed, and no one way except generic plugin to use fingerprint scanner. Please, don't break the last and only possibility.
I have the same problem on: kubuntu 12.04 kdm 4:4.8.5-0ubuntu0.2 Linux PcP01 3.2.0-36-generic-pae #57-Ubuntu SMP Tue Jan 8 22:01:06 UTC 2013 i686 i686 i386 GNU/Linux pcp01 description: Notebook product: 3259A2G (SKU) vendor: LENOVO version: ThinkPad Edge E530 Bus 001 Device 004: ID 147e:1002 Upek
same problem with a lenovo s430 when kdm will support other authentication method?
Are we really still being held back by this 8yr old bug and quite possibly the rudest member of the kde team. You should really be embarrassed by your attitude and inability to work well with people who are genuinely trying to help.
I was tired of waiting and I moved Gnome
Some developers simply don't understand that software is supposed to provide functionality to users rather than it is a way to produce themselves. Just sad, if then they are unable to implement a common feature, and still being rude and arrogant to others who are doing what they can to get it fixed.
Please fix that problem. We are waiting for a long time now. If I can help -> let me know! tx in advance! *using Archlinux @Thinkpad
Wow. The patch is there for 8 years, and still such a common bug is not fixed.
(In reply to comment #52) > Wow. The patch is there for 8 years, and still such a common bug is not > fixed. Is it still working?
*** Bug 329523 has been marked as a duplicate of this bug. ***
Since the folks at KDE can't seem to figure this out (or maybe they don't care to fix it), has anyone found a good patch or work-around? I don't mind hitting a key or clicking a user first if that's the way it must be. I just want it to work. I see Alexey has posted some source code, but is there a script or .deb for the rest of the world?
I installed recently KDE5. I wasn't able to compile fingerprint -9-inch-tablet-PC-battery with newer libs, but fprintd had no problem. Now it works with everything I need - also with KDE's lock screen. So I advice you to upgrade KDE.
Sorry, I'm using SwiftKey and it corrected fingerprint-gui to this strange text, but now I don't see anywhere possibility to edit my previous message.
(In reply to Scott Moore from comment #55) > Since the folks at KDE can't seem to figure this out (or maybe they don't > care to fix it), has anyone found a good patch or work-around? I don't mind > hitting a key or clicking a user first if that's the way it must be. I just > want it to work. I see Alexey has posted some source code, but is there a > script or .deb for the rest of the world? With regard to KDE4, there is only solution use generic kdm plugin from kdm version 4.6. If we talking about installing KDE from packages like .deb or similar, I think you can unpack kdm related files from kde-4.6 package and overwrite corresponding files of your version of kdm. At least in kde-4.11.4 this workaround works fine with fingerprint GUI. Sorry, but for this year I don't update KDE at all and use version 4.11.4 So, I don't know how it works in KDE5.
Just to second the merge of this patch. This would make a lot of ThinkPad KDE users happy. This is the only component not working in Linux (KDE) at the moment.
Hold tight my dear KDE developers! Only a few more months and you'll be celebrating 10 years of this bug! Maybe fingerprint readers will become obsolete by the time...
Just come here for ThinkPad X61 and ASUS R2H support :-)
My English is not very good, excuse me if I said something wrong. More than two years ago I wrote here that fingerprint-gui authentication is broken in kde>4.6, even with generic plugin. Now I have notebook with fingerprint reader and installed KDE 4.11.14. And, as I see, the problem still unsolved. So, since I'm a owner of notebook with fingerprint reader again, and have some free time, I found solution for using kdm with fingerprint-gui (with generic plugin). I make another "completely wrong" patch, for kdm-4.11.14. I think it will fit for later versions kde-4.x too. You need to make some changes in kdmrc for using fingerprint-gui (add a line below following section): [X-*-Greeter] PluginsLogin=generic,classic You should set kdm theme "Oxygen" before make changes in kdmrc, because generic plugin doesn't work with another themes. Screensaver still doesn't work with fingerprint-gui, but I can say that a problem resides in kcheckpass and kscreenlocker_greet. Now I can't find solution, but maybe someone can take a look. Or, maybe developers give us a hint? :) With best regards, Alexey Prokopchuk.
Created attachment 92622 [details] Patch for fingerprint-gui, kdm>4.8
I forgot about policykit authentication. In systemsettings fingerprint-gui work well when user need authenticate for change some privileged items, without any patches, "out of box". It's developers mistake? :)
In addition to last message: I found a workaround for using kscreensaver and kscreenlocker. 1.You need to make changes In kscreensaverrc: PluginsUnlock=generic,classic 2.Variable XAUTHORITY must be set, (in my case is ~/.Xauthority). Fingerprint authentication works well, but fingerprint-gui window is invisible, because kscreenlocker_greet window overlaps it. So, you can simply sweep finger when you see a kscreenlock password prompt, and screen will be unlocked.
And here we are 11 years after, thanks to big ego. Best wishes to all KDE devs for 2016. Let's hope someone with more skills than me will bring KDE to the age of biometry. If not, let's take a rendez-vous for next year to have another best wishes session. And many thanks to Alexey ! You should have improved since all that time ;-) I'm gonna test your workarounds soon on debian strech/testing with a Thinkpad fingerprint reader.
i think kdm is dead now with plasma 5. it's sddm who are used.
Hi Marc You're right : sddm is running in KDE 5.16 for debian stretch : kdm has gone. The present old bug has been "imported" in the github for sddm [see here](https://github.com/sddm/sddm/issues/284) and the discussion there is less dusty.
(In reply to Stéphan Bellegy from comment #68) > The present old bug has been "imported" in the github for sddm [see > here](https://github.com/sddm/sddm/issues/284) and the discussion there is > less dusty. Less dusty until someone else posts a completely wrong patch there too, and another 10 years come and pass waiting for the correct one... <sarcastic mode="off"> <ignorant mode="on" cause="i don't know anything about KDM code"> BTW, the fact that this never got fixed "the right way" in KDM is quite symptomatic of what it used to be only a suspect in my mind: it is KDM being completely wrong, not the patch itself. If implementing alternative authentication methods the right way requires such a big effort, then it is entirely possible that a KDM design flaw is to blame. Anyhow, thanks to everyone for the good work. <silent mode="on">
11 years, so shiny new KDE, but no way to authenticate to it with biometry? If I swipe my finger on locked screen - it's grays out password field, and does nothing, like if I just pressed Enter...
Just hit the problem. Sad. The SDDM, kscreenlock all broken here ;( Fedora 24 64bit SDDM 0.13.0 kscreenlocker 5.7.3
Same here: Kubuntu 16.04. Please fix the problem, it's really poor not to have the fingerprint-reader. Please consider the time used and act soon!
very old issue, amse on kUBUNTU 17.10. Please fix it soon!
KDM is unmaintained and not used in KDE Plasma 5. SDDM is the login manager used in KDE Plasma 5. If you still have this same issue with SDDM, please file an issue on the SDDM bugtracker (after doing a search for existing issues first!): https://github.com/sddm/sddm/issues/