Bug 802435

Summary: remote-viewer does not utilize smart card reader plugged when the client is running
Product: Red Hat Enterprise Linux 6 Reporter: David Jaša <djasa>
Component: libcacardAssignee: David Blechter <dblechte>
Status: CLOSED WONTFIX QA Contact: SPICE QE bug list <spice-qe-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.3CC: cfergeau, cwei, dblechte, hbrock, mkenneth, mkrcmari, mzhan, rbalakri, riehecky, rrelyea, salmy, zpeng
Target Milestone: beta   
Target Release: 6.3   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 801854
: 806038 (view as bug list) Environment:
Last Closed: 2017-12-06 11:03:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 806038, 811314, 975600    
Bug Blocks: 801854    

Description David Jaša 2012-03-12 14:34:04 UTC
Steps to reproduce + environment are the same as in cloned bug, just the client cli is a bit different:
remote-viewer --spice-smartcard spice://<host>/?port=<port>

Actual results:
from user POV: nothing happens
debug console output (no matter if card is pre-inserted or not or how many times it is reinserted):
(remote-viewer:23596): GSpice-DEBUG: usb-device-manager.c:598 device added 0xb92ff0
(remote-viewer:23596): GSpice-DEBUG: smartcard-manager.c:273 smartcard: reader-added
(remote-viewer:23596): GSpice-DEBUG: channel-smartcard.c:314 smartcard: send message 3, queued

Expected results:
remote-viewer recognizes the reader and offers authentication once the card is inserted.

Additional info:
debug output when the reader is plugged in before client start:
(remote-viewer:24142): GSpice-DEBUG: usb-device-manager.c:598 device added 0x20258b0
(remote-viewer:24142): GSpice-DEBUG: usb-device-manager.c:598 device added 0x2025810
(remote-viewer:24142): GSpice-DEBUG: usb-device-manager.c:598 device added 0x20256d0
(remote-viewer:24142): GSpice-DEBUG: usb-device-manager.c:598 device added 0x2025950
(remote-viewer:24142): GSpice-DEBUG: spice-channel.c:124 smartcard-8:0: spice_channel_constructed
(remote-viewer:24142): GSpice-DEBUG: spice-channel.c:2086 Started background coroutine 0x209d998 for smartcard-8:0
(remote-viewer:24142): GSpice-DEBUG: spice-channel.c:1660 smartcard-8:0: spice_channel_recv_link_msg: 1 caps
(remote-viewer:24142): GSpice-DEBUG: spice-channel.c:1084 smartcard-8:0: channel up, state 5
(remote-viewer:24142): GSpice-DEBUG: smartcard-manager.c:424 smartcard_manager_init
(remote-viewer:24142): GSpice-DEBUG: smartcard-manager.c:459 vcard_emul_init
(remote-viewer:24142): GSpice-DEBUG: smartcard-manager.c:470 smartcard_manager_init end: 1
(remote-viewer:24142): GSpice-DEBUG: smartcard-manager.c:273 smartcard: reader-added
(remote-viewer:24142): GSpice-DEBUG: channel-smartcard.c:314 smartcard: send message 3, queued
(remote-viewer:24142): GSpice-DEBUG: smartcard-manager.c:518 smartcard_manager_finish
(remote-viewer:24142): GSpice-DEBUG: channel-smartcard.c:484 smartcard: handle msg 2
(remote-viewer:24142): GSpice-DEBUG: channel-smartcard.c:488 smartcard: in flight 3
// card insert
(remote-viewer:24142): GSpice-DEBUG: smartcard-manager.c:292 smartcard: card-inserted
(remote-viewer:24142): GSpice-DEBUG: channel-smartcard.c:314 smartcard: send message 5, queued
(remote-viewer:24142): GSpice-DEBUG: channel-smartcard.c:484 smartcard: handle msg 2
(remote-viewer:24142): GSpice-DEBUG: channel-smartcard.c:488 smartcard: in flight 5
(remote-viewer:24142): GSpice-DEBUG: channel-smartcard.c:484 smartcard: handle msg 7
(remote-viewer:24142): GSpice-DEBUG: channel-smartcard.c:314 smartcard: send message 7, now
// guest's gdm 

(last two messages repeated many times)


+++ This bug was initially created as a clone of Bug #801854 +++

Created attachment 568960 [details]
backtrace

Description of problem:
spicec crashes (segfaults) when smartcard is plugged while guest expects smartcard auth

Version-Release number of selected component (if applicable):
spice-client-0.8.2-13.el6.x86_64
coolkey-1.1.0-19.el6.x86_64
pcsc-lite-1.5.2-6.el6.x86_64

How reproducible:
always

Steps to Reproduce:
0. unplug the reader from the client
1. boot up the RHEL guest to smartcard-enabled gdm
2. (optional: select "smartcard authentication")
3. run spicec --smartcard <other opts>
4. plug the smartcard reader
  
Actual results:
spicec crashes with segmentation fault

Expected results:
spicec continues running

Additional info:
  * does not happen when sc reader is already plugged in at the launch of spicec
  * messages in log (with DEBUG level) from reader insertion to the crash:
1331309793 INFO [23904:23916] SmartCardChannel::cac_card_events_thread_main: VEVENT_READER_INSERT
1331309793 INFO [23904:23904] SmartCardChannel::add_unallocated_reader: adding unallocated reader 0x960dc0
  * log messages when reader is plugged at spicec launch and spiced does
    not crash:
1331310580 INFO [2326:2338] SmartCardChannel::cac_card_events_thread_main: VEVENT_READER_INSERT
1331310580 INFO [2326:2326] SmartCardChannel::add_unallocated_reader: adding unallocated reader 0x28bae60
1331310580 INFO [2326:2338] SmartCardChannel::cac_card_events_thread_main: VEVENT_CARD_INSERT
1331310580 INFO [2326:2326] SmartCardChannel::add_reader: adding 0x28bae60->0
   * log messages when user removes and re-inserts smartcard:
1331310684 INFO [2326:2338] SmartCardChannel::cac_card_events_thread_main: VEVENT_CARD_REMOVE
1331310691 INFO [2326:2338] SmartCardChannel::cac_card_events_thread_main: VEVENT_CARD_INSERT
1331310692 DEBUG [2326:2326] SmartCardChannel::send_atr: ATR: 
1331310692 DEBUG [2326:2326] VSCMessageEvent::response:   31: recv APDU: 
1331310692 DEBUG [2326:2326] VSCMessageEvent::response:  sent APDU:

--- Additional comment from djasa on 2012-03-09 17:43:29 CET ---

Created attachment 568961 [details]
pcscd debug output from card insertion to client segfault

Comment 1 Alon Levy 2012-03-13 15:44:07 UTC
Please provide debug information from qemu side by passing the debug flag to ccid-card-passthru:

-device ccid-card-passthru,debug=10

# I don't remember the maximum value for debug, 10 should do

Thanks,
Alon

Comment 2 Alon Levy 2012-03-13 16:28:00 UTC
Maybe usbredir took the device? can you try adding "--spice-disable-usbredir" to remote-viewer invocation?

Thanks,
Alon

Comment 3 David Jaša 2012-03-16 09:32:52 UTC
Clearing needinfo, all info requested was provided in a debugging session.

Comment 4 Alon Levy 2012-03-19 13:43:35 UTC
Managed to reproduce locally, thanks for the help.

Alon

Comment 5 Alon Levy 2012-03-22 17:51:25 UTC
The bug is not in virt-viewer, it's in libcoolkey and libcacard:

 coolkey creates a default fake reader and then passes it on to pcscd, confusing it, causing no notifications of new readers.

 libcacard stops the per-module event blocking thread when there are no slots (caused by removing last reader)

Changing component and cloning, have patches for both upstream, will post and start the process of rebasing them.

Alon

Comment 7 Suzanne Logcher 2012-03-23 14:47:02 UTC
This request was evaluated by Red Hat Product Management for inclusion in the
current release of Red Hat Enterprise Linux. Because the affected component is
not scheduled to be updated in the current release, Red Hat is unfortunately
unable to address this request at this time.  It has been proposed for the next
release. If you would like it considered as an exception in the current
release, please ask your support representative.

Comment 12 David Blechter 2012-10-16 14:41:35 UTC
moving to 6.5, the bugs this one is depend on are not fixed yet

Comment 14 RHEL Program Management 2013-10-14 00:46:15 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 16 Mike McCune 2016-03-28 22:26:18 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 17 Jan Kurik 2017-12-06 11:03:04 UTC
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/