On 08/05/2014 05:33 PM, Jeremy White wrote: > 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? I don't know - I haven't considered it in any amount of detail, I was just pointing out the obvious I guess, sorry. I meant simply that if your aim was (which clearly it isn't now) to abstract at the PAM/Credential (might not be the same thing) level you could tailor a protocol for that. > >> 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? I'm not sure - I was thinking a third part, this time it's a bit more complicated, basically having a pcscd driver that would only be used by specific clients (i.e. processes, apps running presumably by the user controlling the Xspice instance). Usage scenario I guess is: 1. user launches Xspice (via some control interface) 2. user starts smartcard using app (i.e. firefox) 3. firefox connects to smartcard via pcscd, pcscd recognized this is supposed to go to the spice-ccid driver (to the *specific* one - you presumably have more then one instance of Xspice with different clients and hence smartcard hardware/credentials connected). You could use some environment variable, or perhaps having more then one instance of pcscd - that would make things simpler at the pcscd level, i.e. it could use a config file running only one driver, spice-ccid, with the correct unix domain socket connecting back to Xspice (spiceqxl_drv.so). > > Cheers, > > Jeremy _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel