This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Hmmmm, looks like the gdm plugin is having a similar issue. Asha, do you have a quick link to the iso you tried out?

thanks,
jack

Did network install from http://download.devel.redhat.com/nightly/latest-RHEL6.0/6.0/Client/i386/os.

var/log/messages has this:

Jun 14 12:32:02 dhcp231-232 abrtd: Package 'gdm-plugin-smartcard' isn't signed
with proper key
Jun 14 12:32:02 dhcp231-232 abrtd: Corrupted or bad crash
/var/spool/abrt/ccpp-1276533122-2041 (res:5), deleting



Ray:

Note in the log  gdm-plugin-smartcard appears to be experiencing similar issues as esc. Does this proper key message ring a bell at all?

Asha:

The only iso I was able to get working was this one:

http://download.devel.redhat.com/nightly/RHEL6.0-20100615.n.1/6.0/Client/i386/os/

After doing so and enabling smart card support, esc came up just fine with a smart card plugged in. Perhaps there is some step I missed?

Further investigation:

This looks like an issue where the esc daemon is crashing because coolkey thinks that the gemalto 64K USB Key is a CAC card. This problem only appears to happen with the gemalto card with USB form factor. Here are the events:

1. User logs in with gemalto 64K USB Key.

2. After typing in the pin, I"m guessing it's the smart card gdm plugin, issues a logout command to the pkcs#11 module. This operation takes about 30 seconds to complete which makes the login take a long amount of time.

3. At this point the login launches the esc daemon program. The first thing this app does is attempt to connect to the token. It first tries to connect to the CoolKey applet because the card really is a coolkey.For some unknown reason, this fails. Then coolkey tries to connect to the CAC applet as normal. Unbelievably, this call is successful. The coolkey token is somehow impersonating a CAC card.

4. From this point on, coolkey tries to load CAC certs that don't exist and a crash is the result.

5. Once the daemon crashes, from this point on, it can be successfully restarted. The original log in seems to have put pcsc-lite in some sort of wired state that only a crash can alleviate.

Below is a quick stack trace of the crash caught in the act:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb77a6b70 (LWP 8325)]
0x0011bac8 in ?? () from /usr/lib/libcoolkeypk11.so
(gdb) where
#0  0x0011bac8 in ?? () from /usr/lib/libcoolkeypk11.so
#1  0x0011bb81 in ?? () from /usr/lib/libcoolkeypk11.so
#2  0x0011d063 in CACCert::CACCert(unsigned char, _CKYBuffer const*) ()
   from /usr/lib/libcoolkeypk11.so
#3  0x00123cc2 in Slot::loadCACCert(unsigned char) ()
   from /usr/lib/libcoolkeypk11.so
#4  0x00124774 in Slot::loadObjects() () from /usr/lib/libcoolkeypk11.so
#5  0x00124da8 in Slot::refreshTokenState() () from /usr/lib/libcoolkeypk11.so
#6  0x001255d3 in Slot::getAttributeValue(SessionHandleSuffix, unsigned long, CK_ATTRIBUTE*, unsigned long) () from /usr/lib/libcoolkeypk11.so
#7  0x001256f8 in SlotList::getAttributeValue(unsigned long, unsigned long, CK_ATTRIBUTE*, unsigned long) const () from /usr/lib/libcoolkeypk11.so
#8  0x0011904c in C_GetAttributeValue () from /usr/lib/libcoolkeypk11.so
#9  0x0728953e in ?? () from /usr/lib/libnss3.so
#10 0x0728962c in PK11_ReadRawAttribute () from /usr/lib/libnss3.so
#11 0x08055b07 in ?? ()
#12 0x0805d74e in ?? ()
#13 0x0805d945 in ?? ()
#14 0x0805dbbd in SmartCardMonitoringThread::LaunchExecute(void*) ()
#15 0x073a8ff2 in ?? () from /lib/libnspr4.so
#16 0x007a7919 in start_thread () from /lib/libpthread.so.0
#17 0x006eae1e in clone () from /lib/libc.so.6


Also, the issue only appears to happen if the system is configured for smart card login and the smartcard is actually used to log into the system. The situation can be easily reproduced by simply locking the screen and unlocking it with the smart card.

Additional debugging would be required to figure out what is going on here.

Created attachment 424904 [details]
Patch to solve the seg fault only

This appears to take care of the cases where esc and Firefox (with coolkey loaded) can crash.

Created attachment 424983 [details]
Improved patch for this issue.

attachment (id=424983) rrelyea+, he observed the creation of the patch.

This fix alleviates the issue with apps loading the coolkey pkcs#11 module and crashing. ESC or Firefox will no longer crash under the circumstances listed in the bug.

This is due to some strange interaction between the gemalto usb card and pcsc-lite. The coolkey thinks this card is a cac card when logging into the desktop. 

The fix prevents crashing and the smartcard is left in a more stable situation. ESC and Firefox can be launched successfully and eventually , after a bit of a delay, the smart card can be detected.

Test this by doing some basic smart card login tests with the usb gemalto 64 card. Also make sure esc or Firefox (with coolkey loaded) does not crash. The issues of a longer login time and occasional esc thinking the key is uninitialized will persist. The underlying issue with pcsc is still to be solved.

Tested smart card login with Gemalto 64K usb token with these components, esc does not crash.

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-15.el6.i686
gdm-2.30.4-13.el6.i686
gnome-screensaver-2.28.3-8.el6.i686
gnome-settings-daemon-2.28.2-11.el6.i686
thunderbird-3.1.1-1.el6.i686
firefox-3.6.8-1.el6.i686


Firefox with coolkey loaded does not crash.

Marking the bug verified.

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.