Description of problem: = Login to the RHEL 6.0 x86 system with a 64k gemalto usb token. Version-Release number of selected component (if applicable): [root@dhcp-115 ~]# rpm -q esc ccid pcsc-lite pcsc-lite-libs coolkey gdm gnome-screensaver gnome-settings-daemon esc-1.1.0-21.el6.i686 ccid-1.3.9-3.el6.i686 pcsc-lite-1.5.2-5.el6.i686 pcsc-lite-libs-1.5.2-5.el6.i686 coolkey-1.1.0-14.el6.i686 gdm-2.30.4-5.el6.i686 gnome-screensaver-2.28.3-6.el6.i686 gnome-settings-daemon-2.28.2-6.el6.i686 How reproducible: - always Steps to Reproduce: 1. enable rhel 6 smartcard logon. 2. set screensaver to lock screen if card is removed. 3. logout. 4. plugin enrolled smartcard. 5. enter smartcard PIN 6. gdm takes a _FEW_ seconds to load and then the screen saver locks the screen. Actual results: - screen locks making the system unusable for anything. Expected results: - screen is not locked and let the user use the desktop Additional info: Logs here - http://pastebin.test.redhat.com/26492
using tree RHEL6.0-20100707.4
notes: - I tried to remove the card and put it back in when the screen is locked == NOTHING Happens. - Screen says at this point - "Please insert a card for user testuser-1" as if it lost the card. But the card is right there in the usb port.
This sounds like the previously reported issue with the gemalto 64K USB style token.
With the CCID reader based card, the following happens: 1. The screen saver locks the card and immediately brings up a box asking for the pin. 2. Inserting the pin allows the user to log in. Attempting with the USB based gemalto, the login takes a few seconds and still immediately locks the screen when login is complete. It then takes a few more seconds to bring up the box asking for the pin. I was then able to remove and place back the key to get a prompt unlike the original report. I believe the known issue with the USB token is causing the side effects, but the main problem is the fact that the screen saver thinks that the token has been removed immediately.
Jack and I found some problem in the driver selection code in GDM. gnome-settings-daemon has the same code, so it has the same problem. It could be the root cause of this issue.
i'm building those changes now
Tested login to the RHEL 6.0 x86 system with a 64k gemalto usb token with 'gnome-settings-daemon-2.28.2-10.el6'. The issues still not fixed completely. 1. The screen saver locks the card and immediately brings up a box asking for the pin. 2. Inserting the pin allows the user to log in. In this case Phone home configuration dialog is displayed (screen-shot attached). ESC Smartcard manager shows the status of the token as 'Logged In'.
Created attachment 435071 [details] Screen-shot for the comment Comment #7.
So just so I understand, 1) Boot the computer, and wait until login screen loads 2) Insert smart card 3) Type PIN into login screen 4) Wait for login to finish. At this point... 5) The screensaver locks 6) The unlock dialog pops up as soon as locking is finished 7) Typing the PIN code into the unlock dialog unlocks the screen 8) Sitting there already loaded is esc asking for a phone home url Is this correct?
Ray, the gemalto 64K token is not recognized during login when I just did this: 1) Boot the computer, and wait until login screen loads 2) Insert smart card It hangs in the 'Smartcard Authentication' dialog. So, the correct steps to reproduce the issue is: 1) Boot the computer, and wait until login screen loads, click on 'Smartcard Authentication' login option. 2) Insert smart card 3) Type PIN into login screen 4) Wait for login to finish. At this point... 5) The screensaver locks 6) The unlock dialog pops up as soon as locking is finished 7) Remove the token from the usb drive and re-insert, typing the PIN code unlocks the screen 8) Sitting there already loaded is esc asking for a phone home url.
Asha, can you post the versions of package used. like, gdm,gnome-settings-daemon,gnome-screensaver,gdm-plugin-smartcard,coolkey so we know you have the latest...
Here is the list of packages that are on my desktop: gdm-2.30.4-13.el6 gnome-settings-daemon-2.28.2-10.el6 gnome-screensaver-2.28.3-8.el6 gdm-plugin-smartcard-2.30.4-13.el6 coolkey-1.1.0-14.el6 pcsc-lite-1.5.2-6.el6
What's your screensaver timeout set to? gconftool-2 -R /apps/gnome-screensaver If your timeout is set to 1 minute or something it could be log in is so slow the screensaver inactivity timer is kicking in.
Ray, which attribute in this output is for screen saver timeout? [tester@dhcp231-232 ~]$ gconftool-2 -R /apps/gnome-screensaver lock_enabled = true idle_activation_enabled = true cycle_delay = 10 status_message_enabled = true mode = single user_switch_enabled = true idle_delay = 10 logout_delay = 120 power_management_delay = 30 embedded_keyboard_enabled = false logout_enabled = false embedded_keyboard_command = logout_command = themes = [blank-only] lock_delay = 0
Sorry it moved and I forgot, it's /desktop/gnome/session/idle_delay can you post gconftool-2 -R /desktop/gnome/session ? I've spent some time trying to reproduce. I haven't been able to yet.
[tester@dhcp231-232 ~]$ gconftool-2 -R /desktop/gnome/session required_components_list = [windowmanager,panel,filemanager] max_idle_time = 120 default_session = [gnome-settings-daemon] idle_delay = 5 max_idle_action = /desktop/gnome/session/required_components: filemanager = nautilus windowmanager = metacity panel = gnome-panel
i'm assuming login is shorter than 5 minutes, so that's not it.
I talked to Asha about this yesterday. We're going to try to find what's different between her environment and mine tomorrow.
There have been some new changes to GDM recently that Asha says have made this problem go away. The changes are unrelated to this bug, but have to do with the the length of time messages are getting displayed on screen. That could mean 1) The issue is timing specific and the extra time is making this bug not trigger anymore 2) The issue was just the hardware being flaky
Asha's going to try reproducing the problem again by downgrading GDM
Downgraded gdm packages to: gdm-2.30.4-13.el6 gdm-libs-2.30.4-13.el6 gdm-plugin-smartcard-2.30.4-13.el6 gdm-plugin-fingerprint-2.30.4-13.el6 Unable to reproduce the issue mentioned in comment 10. Test is performed with the same smart card token (hardware) as earlier. Noticed that when I upgraded the system (yum -y update) few other smart card login related packages (gnome-settings-daemon, coolkey, pam_pkcs11 etc) got updated as well. With the system upgraded to the latest packages, I am not able to reproduce the problem mentioned in comment 10. Screen does not lock immediately after login with smart card. Packages with version number: ccid-1.3.9-3.el6.i686 pcsc-lite-1.5.2-6.el6.i686 pcsc-lite-libs-1.5.2-6.el6.i686 coolkey-1.1.0-15.el6.i686 gdm-2.30.4-15.el6.i686 gdm-libs-2.30.4-15.el6.i686 gnome-screensaver-2.28.3-8.el6.i686 gnome-settings-daemon-2.28.2-11.el6.i686 pam_pkcs11-0.6.2-8.el6.i686 After a successful login to Rhel 6 desktop with Gelmalto 64K usb token, ESC Smartcard manager does not show the token details. Also, pklogin_finder fails to recognize token. [tester@dhcp231-173 ~]$ pklogin_finder debug DEBUG:pam_config.c:238: Using config file /etc/pam_pkcs11/pam_pkcs11.conf DEBUG:pkcs11_lib.c:182: Initializing NSS ... DEBUG:pkcs11_lib.c:192: Initializing NSS ... database=/etc/pki/nssdb DEBUG:pkcs11_lib.c:210: ... NSS Complete DEBUG:pklogin_finder.c:71: loading pkcs #11 module... DEBUG:pkcs11_lib.c:222: Looking up module in list DEBUG:pkcs11_lib.c:225: modList = 0x97c8658 next = 0x97c9fb8 DEBUG:pkcs11_lib.c:226: dllName= <null> DEBUG:pkcs11_lib.c:225: modList = 0x97c9fb8 next = 0x0 DEBUG:pkcs11_lib.c:226: dllName= libcoolkeypk11.so DEBUG:pklogin_finder.c:79: initialising pkcs #11 module... PIN for token: DEBUG:pkcs11_lib.c:48: PIN = [Secret123] DEBUG:pkcs11_lib.c:753: no certs found found DEBUG:pklogin_finder.c:119: get_certificate_list() failed: /var/log/messages has utils.c:123:StatSynchronize() Can't open /var/run/pcscd.events/event.2148.16984812: Bad file descriptor and other pcscd related messages: Aug 6 16:32:20 dhcp231-173 pcscd: winscard.c:362:SCardConnect() Card Not Inserted Aug 6 16:32:20 dhcp231-173 pcscd: ifdhandler.c:1091:IFDHTransmitToICC() usb:08e6/3438:libhal:/org/freedesktop/Hal/devices/usb_device_8e6_3438_noserial_if0 (lun: 10000) Aug 6 16:32:20 dhcp231-173 pcscd: ifdhandler.c:1091:IFDHTransmitToICC() usb:08e6/3438:libhal:/org/freedesktop/Hal/devices/usb_device_8e6_3438_noserial_if0 (lun: 10000) Aug 6 16:32:20 dhcp231-173 pcscd: ifdhandler.c:1091:IFDHTransmitToICC() usb:08e6/3438:libhal:/org/freedesktop/Hal/devices/usb_device_8e6_3438_noserial_if0 (lun: 10000) Aug 6 16:32:20 dhcp231-173 pcscd: ifdhandler.c:1091:IFDHTransmitToICC() usb:08e6/3438:libhal:/org/freedesktop/Hal/devices/usb_device_8e6_3438_noserial_if0 (lun: 10000) Aug 6 16:32:20 dhcp231-173 pcscd: ifdhandler.c:1091:IFDHTransmitToICC() usb:08e6/3438:libhal:/org/freedesktop/Hal/devices/usb_device_8e6_3438_noserial_if0 (lun: 10000) Aug 6 16:32:20 dhcp231-173 pcscd: winscard.c:362:SCardConnect() Card Not Inserted Aug 6 16:32:20 dhcp231-173 pcscd: winscard.c:362:SCardConnect() Card Not Inserted Aug 6 16:32:23 dhcp231-173 pcscd: winscard.c:362:SCardConnect() Card Not Inserted Aug 6 16:32:23 dhcp231-173 pcscd: ifdhandler.c:1091:IFDHTransmitToICC() usb:08e6/3438:libhal:/org/freedesktop/Hal/devices/usb_device_8e6_3438_noserial_if0 (lun: 10000) Aug 6 16:32:23 dhcp231-173 pcscd: ifdhandler.c:1091:IFDHTransmitToICC() usb:08e6/3438:libhal:/org/freedesktop/Hal/devices/usb_device_8e6_3438_noserial_if0 (lun: 10000) Aug 6 16:32:23 dhcp231-173 pcscd: ifdhandler.c:1091:IFDHTransmitToICC() usb:08e6/3438:libhal:/org/freedesktop/Hal/devices/usb_device_8e6_3438_noserial_if0 (lun: 10000) Aug 6 16:32:23 dhcp231-173 pcscd: ifdhandler.c:1091:IFDHTransmitToICC() usb:08e6/3438:libhal:/org/freedesktop/Hal/devices/usb_device_8e6_3438_noserial_if0 (lun: 10000) Assigning this bug to Ray, marked pam_pkcs11 as the component. This issue could be related to the card timing out and then nss losing track of it because of that.
So I spent quite some time looking into this today, but don't know what the root problem is. What I can say is that the problems mentioned in comment 21 definitely seem to be be related to the initial delay at login. And also, that delay is triggered by initiating a logout command to the card. Once the logout command is initiated, it sits there for several seconds waiting for a response in the ReadUSB call until it finally gets one. That response has a status of "COMMAND FAILED" with an error of "0xFE Card absent or mute". From that point on chaos sets in and things don't work very well. One thing that's interesting, is if I change coolkey to make logout a no-op that just returns CKYSUCCESS instead of calling CKYApplet_HandleAPDU(conn, CKYAppletFactory_Logout, &pinNumber, ...) then everything works fine. This may be an okay workaround--I don't really know the implications of the change. I assume it means we aren't doing some clean up, and that clean up by important if it's for a finite set of resources. If we did go with a workaround like that, we'd probably want to move it it to some other part of the stack and only do it for the problematic card model. The right fix for this may ultimately end up being something that needs to get put into the java code that the smartcards get formatted with, and not anything on the OS side, I don't know. I think we really need Bob's expertise here.
Interesting findings. This was not an issue in 5 so we suspected some weird interaction between this card and either pcsc or the reader driver. I can take a look to see what the Logout function in the applet is doing.
<poof: Bob appears as a genie on invocation of just his name;)> added self to CC list. So, This is a Gemalto running coolkey? Hmm, so not logging out of coolkey is not as big an issue as it is for other cards. If you simply forget the nonce, you will effectively be logged out. There is an internal state in the card that says how many users are logged in, and that will be wrong if we don't call logout, but no one will be able to use the card without getting the nonce. For now in RHEL-6 that may be OK, I think the real "fix" for the Gemalto cards, however, see the the applet is doing that is causing the card such headaches (probably doing a reset or something). We can probably get around that in the applet. NOTE: we we are talking about a CAC version, then skipping the Logout is NOT ok. Login/logout state is global to the token, not local to the process for CAC. bob
So Jack, Bob, and I spent some time today debugging this issue. It seems to be a problem in the card applet with the apdu.setIncomingAndReceive() call in verifySecureNonce(). That call blocks indefinitely for Logout calls with this particular hardware. Jack is going to try to reproduce this problem on RHEL5, and see if it's a preexisting issue. We can work around the problem by avoiding calling verifySecureNonce() for logout commands. It's not super important to authenticate logout for these particular cards anyway. We think it makes the most sense to use a work around in the applet code rather than a work around in the OS code (like I was proposing in comment 22). That means this isn't a RHEL bug, but an RHCS bug, so moving products. I do think it would be a good idea to have a release note about this issue, however.
Jack just confirmed that this problem happens on rhel 5 as well, so I don't think a release note is that important either.
Created attachment 438251 [details] Rough patch to work around this issue. Including rough patch for the coolkey applet that works around the issue so we don't lose it.
Created attachment 473947 [details] Simpler patch for this issue. Bob R please review. This is the patch we already tested some time ago.
Comment on attachment 473947 [details] Simpler patch for this issue. r+ I would also be tempted to add some comments around the throw exceptions explaining that the 64K gemalto USB token is bogus and doesn't like these calls. Probably you may word it more nicely;). It kind of bothers me that we can't throw an error on these kinds of inputs. Technically this means someone could force your coolkey to logout without logging into it to begin with. bob
Thanks Bob: Comments sound like a good idea, I'll add those.
Checkins: cvs commit -m "Fix Bugzilla Bug 614639 - 64k gemalto usb token no longer works properly after a "logout" request is issued." cvs commit: Examining . Checking in CardEdge.java; /cvs/dirsec/coolkey/applet/src/com/redhat/ckey/applet/CardEdge.java,v <-- CardEdge.java new revision: 1.4.2.3; previous revision: 1.4.2.2 done Running syncmail... Mailing relnotes... ...syncmail done. Running syncmail... Mailing cvsdirsec... ...syncmail done.
Created attachment 475508 [details] Patch to include new applet in TPS
Comment on attachment 475508 [details] Patch to include new applet in TPS PKI_8_BRANCH only
Checkins: Branch: svn commit -m "Fix Bugzilla Bug 614639- 64k gemalto usb token no longer works properly after a "logout" request is issued" 1.4.4d40a449.ijc Adding (bin) 1.4.4d40a449.ijc Transmitting file data . Committed revision 1780. svn commit -m "Fix Bugzilla Bug 614639- 64k gemalto usb token no longer works properly after a "logout" request is issued" Sending tps/Makefile.am Sending tps/Makefile.in Sending tps/doc/CS.cfg Transmitting file data ... Committed revision 1781.
Checkins: Trunk: svn commit -m "Fix Bugzilla Bug 614639- 64k gemalto usb token no longer works properly after a "logout" request is issued" 1.4.4d40a449.ijc Adding (bin) 1.4.4d40a449.ijc Transmitting file data . Committed revision 1782.
Checkins: Trunk: svn commit -m "Fix Bugzilla Bug 614639- 64k gemalto usb token no longer works properly after a "logout" request is issued" Sending tps/CMakeLists.txt Sending tps/Makefile.am Sending tps/Makefile.in Sending tps/doc/CS.cfg.in Transmitting file data .... Committed revision 1783.
Test: 1. Install new TPS instance which includes this new applet. 2. Format and enroll a Gemalto 64K USB token 3. Watch the logs to make sure that applet 1.4.4d40a449.ijc is getting loaded. 4. Attempt basic smart card login tests to make sure the problem is addressed.
Tested with Gemalto 64K usb smart card enrolled with latest CS 8.1 TPS instance (pki-tps-8.1.0-9.el5pki and redhat-pki-tps-ui-8.1.0-3.el5pki) and Smart card login on RHEL 6.1 with the following packages installed: esc-1.1.0-21.el6.i686 ccid-1.3.9-3.el6.i686 pcsc-lite-1.5.2-6.el6.i686 pcsc-lite-libs-1.5.2-6.el6.i686 coolkey-1.1.0-17.el6.i686 gdm-2.30.4-21.el6_0.1.i686 gnome-screensaver-2.28.3-8.el6.i686 gnome-settings-daemon-2.28.2-11.el6.i686 -During smart card enrollment, applet 1.4.4d40a449 is loaded. -Login to the desktop with the smart card works fine. -After the login, manually lock the screen, screen saver is unlocked with the same token successfully. -Login to the desktop with the smart card with card removal action is "Lock", remove the token from the hook, screen saver is activated, screen saver is unlocked successfully with the same smart card and the correct pin. -Login with the smart card, logout and login back with the same token works fine. -Visiting SSL secured web page using certificates on the token is successful. Marking the bug verified.