Version: (using KDE KDE 3.0) Installed from: RedHat RPMs OS: Linux The PAM conversation function as implemented by kdm in kdm/backend/client.c is very broken. I'm currently developing a module for additonal authentication which uses a chipcard + PIN besides the normal username + passwd combo. It is very microsoftish to assume that a call to the conversation function asking for prompt_echo_on always wants the username and prompt_echo_off always wants the passwd, it could also be asking for a PIN code for example. Also the text_info request should be displayed immediatly not after the pam_authenticate function has completed, if I want to display insert chipcard, then the pam_authenticate function will wait untill the chipcard is inserted, and since the request is not displayed untill the function ends this ends in a catch 22. It should also be possible to display mutiple text_info strings. So in short its just broken and needs a complete rewrite IMHO. I'll attach a very simple pam module src, just "make install" and add it too /etc/pam.d/login to see how it is supposed to work. Then try to get it to work under kdm.
Created attachment 14 [details] Simple pam module requesting the user to type "aap" as authentication
I've also reported this to XFree86.org since xdm suffers from the same problem. Unfortunatly they don't have a bugtracking system, I did give this bug id to them.
fixing this is quite high on my todo list.
*** Bug 51863 has been marked as a duplicate of this bug. ***
amazingly enough, after only a year after i promised i'll do it soon (and two and a half year after i planned it at all), i finally fixed it for kde 3.2. additionally to changing the "conversation architecture" i developed a plugin system for the greeter ... PAM is simply too sequentially text oriented to make a really nice GUI without specializing it on a particular authentication scheme.
I just tested kdm-3.2.3 and the pam_aap module attached to this bug report still doesn't work. The whole idea behind the pam conversation mechanism is that new authentication schemes can be added which interact with the user, without having to rewrite every app which needs autnethication. This plugin solution, thus is not a solution as long as there isn't a default fallback which works for all pam conversations. Currently kdm is just unusable for people who wish to really use pam. Having to write a plugin for each new pam module defeats the entire purpose of pam.
so far the theory. in practice, pam is utter crap by design. it works fairly well with authentication methods that require only text prompts (and i plan to write a "generic" plugin that supports this out of the box), but that's it. for other authentication methods it utterly sucks. the only thing you can do in a module is to print a message and hang in your own event loop. this as two problems: a) well, it hangs and b) how can a gui know whether the message is a prompt or an information message? it works on ttys, as for them this doesn't matter. linux-pam tried to solve some problems with BINARY_PROMPT and pam_client, but it just doesn't go far enough, it only solves problem a). actually, the "prompt problem" is not generically solvable, as some prompts will require user input from the terminal, so just displaying a random message as a prompt will remain insufficient. apart from that, even the pam gurus do not agree on central questions like the calling order of pam_setcred and pam_open_session. how much universality can such a system offer?
I see this bug is mared resoved, but nothing in the bug mentions a solution. KDM does not handle securID logins for me on debian sarge (kde 3.2.3). I concede that pam is broken in the sense of a GUI login, but I still am stuck trying to get KDM working for securID logins (enter a passcode after the password) Is there a solution to get this functional at this point? Our securID logins work with GDM, but GDM is broken in many other senses, and since we do not support Gnome, we would like to have a consistant look (KDE).
the solution is to write a fitting conversation plugin. that would be either a specialized one with three fields or the generic one i mentioned (and still didn't write for lack of personal interest). in which regards is gdm broken in which kdm is not? good propaganda is always welcome. :)
I am not much of a programmer, though I do know a little c/c++. How difficult would it be to write such a plugin? Are there any documents decribing how to do this or some examples? A quick google search yeilded me nothing. GDM does not support all of the extra prompting from pam either- if your password has expired (with our Kerberos+SecurID setup) it asks you for your current password forever. Also, in its current form we cannot remove the "Default" or "FailSafe" session options, they seem to be hard-coded in.
> Are there any documents decribing how to do this or some examples? > you know at least one example - the standard user/passwd plugin. ;) there is also one optimized for winbind (with a domain selector). kdebase/kdmlib/kgreet* > Also, in its current form we cannot remove the "Default" or "FailSafe" > session options, they seem to be hard-coded in. > RTFM ;) [it's refreshing to say this, because being able to do it for your own oss program is something exceptional. :)))]
Perhaps you could point to the url of the FM because the one on docs.kde.org seems to be silent on the topic. The same question has been asked on kde-kiosk yesterday.
http://docs.kde.org/en/3.4/kdebase/kdm/different-window-managers-with-kdm.html