Hi Douglas, Thanks for the reply. Interesting point about building the pam module correctly. I've been doing it per the linux pam module writer's guide and other pam module sources (like pam_pkcs11). >From : >http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/mwg-introduction-synopsis.html > :
#include <security/pam_modules.h> gcc -fPIC -c pam_module.c gcc -shared -o pam_module.so pam_module.o -lpam Except that I use g++ instead of gcc, add the include dir for PCSC, and -lpcsclite. In the past, when a library was missing from the link line, when I had more stuff, the module would simply fail to load. A note showed up in /var/log/messages, and pam_unix kicked in immediately. How else would you recommend I ensure that there are no library conflicts? I did examine the pam_pkcs11 module, and found that it appears to use this gdm-restart on card-event functionality in it's design. In short, I believe it attempts to read a card, and if an error happens, it prompts the user with "insert card or type username". If a card is inserted, gdm restarts and upon now being able to read the card, it prompts for the pin. At any point in the process, if you generate a card event by removing or inserting, the pam_pkcs11 module starts all over again. In fact, I have even observed this behavior on a standard RHEL 5.5 and CentOS5 machine. If the pcscd is launched at boot, card events during login restart the process. For example, if a usb reader (I'm using a gemplus) is plugged in with the card removed, and the machine is restarted, the login prompt should appear asking for a username (pam_unix). After typing a username, if at the password prompt you type nothing and instead insert the card into the reader, after a moment the username prompt will re-appear, and gdm has restarted the pam stack. It is my belief that my signal 11 is caused because the thread blocks waiting for card events in my sample module that calls pcsclite methods, and when finished a delayed restart that was attempting to start pam over again causes the fault. At least, this is my theory until I dig more into the pcsclite, pam_pkcs11, and possibly even gdm code. Any thoughts or comments would be greatly appreciated. It is relatively important that I straighten this out, or come up with a workaround at least. Thanks again Matt -----Original Message----- From: [email protected] on behalf of Douglas E. Engert Sent: Tue 10/5/2010 11:14 AM To: [email protected] Subject: Re: [Muscle] pcsc and gdm You may have a library conflict as GDM and pam will have loaded into the process almost every shared labrary, from X11, LDAP, nss, Kerberos, OpenSSL ... make sure your pam module is linked as a module, so it gets the right versions of routines, not some duplicate named routine from some previously loaded module. You can also have your module write a lot of debug output to syslog. Have you looked at any of the pam PKCS#11 modules? Google for: gdm smart card. For example there are a number of pam_krb5 modules that can use smart cards to authenticate to Kerberos or Windows AD using the Kerberos PKINIT protocol, and they work from GDM, and use pcscd. There is also the OpenSC pam_pkcs11 module for local authentication. On 10/4/2010 8:41 PM, Matthew Brown wrote: > Hello, > I realize this has been discussed before, yet I failed to find something > directly relevant to my issue. > I am somewhat new to writing PAM modules and using PCSC, however, after > much research and trying I cannot get around this. > Although my final problem is entrenched in a larger set of code, I have > managed to isolate the issue I am experiencing to a fairly simple PAM > module that I have put into the gdm stack. Basically, in > pam_authenticate, I do the following (pseudo-code) : > > pam_prompt : "enter YES to try the card" > { > if YES, then perform a very basic PCSC set of calls : > GetContext > GetReaders > GetStateChange - passing UNAWARE to get the current state > GetStateChange - block with some reasonable timeout, awaiting a state > other than the initial > ReleaseContext > pam_prompt: "done. card event or timeout over. enter anything to continue" > } > > return PAM_SUCCESS > > This module is entered as "auth required test_module.so", which will > return success and continue to PAM_UNIX and ask for a username and password. > When I run the same set of PCSC calls in a simple app from the command > line, i.e. NOT from within the GDM PAM environment, everything is fine. > However, when I actually logout and get GDM to run my module, it is my > belief that any actual state change that occurs with my single usb card > reader causes PAM to restart the GDM login process. What I experience is > the first prompt, to which I enter "YES", then either insert or remove > the card, and I quickly see the final "done. card event" prompt, yet > very quickly it will reset the process - the screen blinks and I am > prompted again with "enter YES...". If I initially enter "NO", I am > taken right to the standard username prompt, as expected. > > A look at the /var/log/messages file reveals a few hints : > > gdm[pid] : conversation failed > gdm[pid] : gdm_cleanup_children: child [...] crashed of signal 11 > gdm[pid] : gdm_cleanup_children: slave crashed, killing it's children > > and /var/log/secure has something like this : > > pam_succeed_if(gdm:auth) error retrieving user name: Conversation error > > This looks to me like a segfault occured somewhere, the result of which > is that PAM was unable to get my username, either because of or after > which it restarts. Yet as I said, when I run this exact set of PCSC > calls as a simple command line application through valgrind and gdb, all > is well. If I use this PAM module through SU, it also works without a hitch. > > Any advice or help is appreciated. > Thanks much > > > > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert <[email protected]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
<<winmail.dat>>
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
