Thanks!
I'm going to mostly repeat what I think you just said to make sure I
understand you; please correct me if I get it wrong.
Yes. But just note that spice-server doesn't do anything except move
bytes around. The actual protocols involved are:
qemu: ccid protocol: usb smartcard reader
spice-client via libcacard: smartcard
Ah, okay; so Spice just relays bits from libcacard, it doesn't interpret
them in any way. Makes sense.
There are a few things you can do:
1. same components, minus usb bus
nss-libcacard-APDU-[:removed: ccid_device]-[:removed: usb
bus]-[:removed: usb bus driver]-[:new: spiceccid pcsc
module]-pcscd-pam_pkcs11/coolkey
Okay, I think that lines up with some further research I did. That is,
it seems like a good approach appears to be to write a driver to
interface with pcsc-lite (e.g. a bundle to go into
/usr/lib64/pcsc/drivers). I think that would then make the flow
something like this:
client hardware <--> spice-gtk (using libcacard library)
spice-gtk <--> spice-server (spice protocol)
spice-server <--> new spiceccid module
(unknown protocol, probably libcacard influenced)
spiceccid <--> pcsc-lite.so (driver/bundle interface)
pcsc-lite then connects to applications (e.g. pam) as usual
That seem about right?
2. new protocol - I guess you ruled that out already.
I didn't even consider it; I just imagined that reusing the existing
channels was the smart approach. Did I miss a better path by thinking
inside the box?
3. pam modlue consuming APDUs from card - what you proposed - same as 1
but using a pam module to consume the APDUs.
Yeah, I think approach #1 is better.
In fact, it looks like we could hook at many points in the stack; we
could hook at the pam level, at the coolkey level, the pcsc-lite level,
and potentially even at the ccid level (e.g. below ccid). But my (still
naive and limited) instincts suggest that we want a peer to the ccid
module, which is what I understand #1 to be.
And, finally, if that's all right - on to the next question: where
should spiceccid fit in the XSpice stack? Should it be part of the Xorg
driver? Should it be a vd_agent process?
Cheers,
Jeremy
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel