Bug 105631 - fully support alternative authentication methods
Summary: fully support alternative authentication methods
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kdm
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal with 1826 votes (vote)
Target Milestone: ---
Assignee: kdm bugs tracker
URL:
Keywords:
: 182623 183643 329523 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-05-13 22:56 UTC by Alon Bar-Lev
Modified: 2018-10-23 15:07 UTC (History)
44 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Diff - allow PAM to set the user id (493 bytes, patch)
2005-05-13 22:59 UTC, Alon Bar-Lev
Details
kdm-3.5.4-pam.patch (345 bytes, patch)
2006-10-06 19:57 UTC, Alon Bar-Lev
Details
patch for fingerprint-gui (kdm-4.6.0) (5.60 KB, patch)
2011-02-28 20:26 UTC, Alexey Prokopchuk
Details
Patch for fingerprint-gui, kdm>4.8 (412 bytes, patch)
2015-05-15 15:44 UTC, Alexey Prokopchuk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alon Bar-Lev 2005-05-13 22:56:55 UTC
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.
Comment 1 Alon Bar-Lev 2005-05-13 22:59:31 UTC
Created attachment 11032 [details]
Diff - allow PAM to set the user id
Comment 2 Oswald Buddenhagen 2005-05-14 08:26:06 UTC
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
Comment 3 Alon Bar-Lev 2005-05-14 15:27:26 UTC
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.
Comment 4 Alon Bar-Lev 2005-05-14 18:01:56 UTC
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.
Comment 5 Alon Bar-Lev 2005-05-14 18:06:09 UTC
Please disregard last comment. Wrong post.
Comment 6 Oswald Buddenhagen 2005-05-15 00:09:10 UTC
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).
Comment 7 Alon Bar-Lev 2005-05-15 10:32:18 UTC
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.
Comment 8 Oswald Buddenhagen 2005-05-15 11:04:31 UTC
> 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.
Comment 9 Alon Bar-Lev 2005-05-15 12:52:15 UTC
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?
Comment 10 Alon Bar-Lev 2005-05-16 22:03:33 UTC
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.
Comment 11 Oswald Buddenhagen 2005-05-16 22:59:29 UTC
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.
Comment 12 Alon Bar-Lev 2005-05-17 09:55:07 UTC
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?
Comment 13 Oswald Buddenhagen 2005-05-17 10:33:51 UTC
> 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. ;)
Comment 14 Alon Bar-Lev 2005-05-17 13:02:05 UTC
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?
Comment 15 Oswald Buddenhagen 2005-05-18 00:17:29 UTC
> 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).
Comment 16 Alon Bar-Lev 2005-05-18 18:03:49 UTC
>> 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.
Comment 17 Oswald Buddenhagen 2005-05-18 18:32:41 UTC
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.
Comment 18 Alon Bar-Lev 2005-05-18 20:19:48 UTC
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
Comment 19 Oswald Buddenhagen 2005-05-18 21:05:59 UTC
> 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*.
Comment 20 Alon Bar-Lev 2005-05-18 21:22:23 UTC
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.
Comment 21 Oswald Buddenhagen 2005-05-18 21:50:44 UTC
> 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 ...
Comment 22 Alon Bar-Lev 2006-10-06 19:57:29 UTC
Created attachment 18041 [details]
kdm-3.5.4-pam.patch
Comment 23 Oswald Buddenhagen 2009-02-02 20:17:46 UTC
*** Bug 182623 has been marked as a duplicate of this bug. ***
Comment 24 Oswald Buddenhagen 2009-02-02 20:26:05 UTC
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
Comment 25 Wolfgang Ullrich 2009-02-03 10:48:45 UTC
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.
Comment 26 Oswald Buddenhagen 2009-02-08 02:12:03 UTC
*** Bug 183643 has been marked as a duplicate of this bug. ***
Comment 27 Oswald Buddenhagen 2009-02-08 02:15:02 UTC
adjusting title to cover the entire scope of the problem.
Comment 28 Pac Shady 2009-10-15 10:33:10 UTC
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.
Comment 29 Daniel Weigl 2009-11-19 21:29:05 UTC
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.
Comment 30 omega 2010-11-02 16:02:29 UTC
please add full PAM-support to KDM
Comment 31 Alexey Prokopchuk 2011-02-28 20:22:27 UTC
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.
Comment 32 Alexey Prokopchuk 2011-02-28 20:26:33 UTC
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
Comment 33 Oswald Buddenhagen 2011-02-28 22:08:01 UTC
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).
Comment 34 Alexey Prokopchuk 2011-02-28 22:22:23 UTC
(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.
Comment 35 Alexey Prokopchuk 2011-02-28 22:40:35 UTC
> 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.
Comment 36 Ariel Garcia 2011-02-28 23:31:04 UTC
@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.
Comment 37 Alexey Prokopchuk 2011-03-01 03:02:48 UTC
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.
Comment 38 Oswald Buddenhagen 2011-03-01 10:00:04 UTC
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?
Comment 39 Alexey Prokopchuk 2011-03-01 13:33:25 UTC
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.
Comment 40 Oswald Buddenhagen 2011-03-01 13:58:52 UTC
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.
Comment 41 Alexey Prokopchuk 2011-03-02 02:25:45 UTC
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.
Comment 42 Csaba Kertész 2012-03-20 22:41:41 UTC
KDE. 2012. Fingerprint auth does not work out-of-the-box with a small nice GUI.
RIDICULOUS JOKE.
Shame on you.
Comment 43 Torsten Römer 2012-06-24 23:34:01 UTC
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.
Comment 44 Ariel Garcia 2012-06-25 22:16:55 UTC
<sarcasm>
Perhaps Kubuntu used the completely wrong patch posted by Alexey  ;-P
</sarcasm>
Sorry, couldn't resist ;-)
Comment 45 Alexey Prokopchuk 2012-11-18 20:47:12 UTC
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.
Comment 46 Valter 2013-01-22 08:47:30 UTC
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
Comment 47 Marc Collin 2013-04-07 19:58:02 UTC
same problem with a lenovo s430
when kdm will support other authentication method?
Comment 48 jenna 2013-06-18 03:35:57 UTC
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.
Comment 49 przekop 2013-06-18 09:33:10 UTC
I was tired of waiting and I moved Gnome
Comment 50 Torsten Römer 2013-06-18 11:41:42 UTC
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.
Comment 51 mstl 2014-01-17 11:50:17 UTC
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
Comment 52 constantius9 2014-02-09 10:02:00 UTC
Wow. The patch is there for 8 years, and still such a common bug is not fixed.
Comment 53 Marek Pikuła 2014-03-10 21:49:32 UTC
(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?
Comment 54 Oswald Buddenhagen 2014-03-31 14:11:52 UTC
*** Bug 329523 has been marked as a duplicate of this bug. ***
Comment 55 Scott Moore 2014-12-06 01:51:06 UTC
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?
Comment 56 Marek Pikuła 2014-12-06 08:02:28 UTC
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.
Comment 57 Marek Pikuła 2014-12-06 08:04:58 UTC
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.
Comment 58 Alexey Prokopchuk 2014-12-06 10:46:13 UTC
(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.
Comment 59 enno 2015-01-09 08:10:07 UTC
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.
Comment 60 Lucio Crusca 2015-01-09 09:12:21 UTC
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...
Comment 61 V字龍(Vdragon) 2015-01-16 21:16:48 UTC
Just come here for ThinkPad X61 and ASUS R2H support :-)
Comment 62 Alexey Prokopchuk 2015-05-15 15:35:36 UTC
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.
Comment 63 Alexey Prokopchuk 2015-05-15 15:44:46 UTC
Created attachment 92622 [details]
Patch for fingerprint-gui, kdm>4.8
Comment 64 Alexey Prokopchuk 2015-05-15 16:00:42 UTC
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? :)
Comment 65 Alexey Prokopchuk 2015-05-20 14:24:01 UTC
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.
Comment 66 Stéphan Bellegy 2016-01-03 19:03:45 UTC
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.
Comment 67 Marc Collin 2016-01-04 00:06:15 UTC
i think kdm is dead now with plasma 5.

it's sddm who are used.
Comment 68 Stéphan Bellegy 2016-01-04 17:52:54 UTC
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.
Comment 69 Lucio Crusca 2016-01-04 19:38:59 UTC
(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">
Comment 70 Eugene Lopatin 2016-06-02 18:30:24 UTC
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...
Comment 71 Jacek Pawlyta 2016-08-14 10:30:29 UTC
Just hit the problem. Sad. The SDDM, kscreenlock all broken here ;( 
Fedora 24  64bit
SDDM 0.13.0
kscreenlocker 5.7.3
Comment 72 Jacek Pawlyta 2016-08-14 10:30:51 UTC
Just hit the problem. Sad. The SDDM, kscreenlock all broken here ;( 
Fedora 24  64bit
SDDM 0.13.0
kscreenlocker 5.7.3
Comment 73 Michael 2016-08-15 17:44:47 UTC
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!
Comment 74 Michael 2018-02-22 18:52:50 UTC
very old issue, amse on kUBUNTU 17.10. Please fix it soon!
Comment 75 Nate Graham 2018-04-16 20:19:48 UTC
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/