On Mon, Jan 17, 2011 at 03:23:55PM +0200, Alon Levy wrote:
On Mon, Jan 17, 2011 at 11:17:07AM +0000, Daniel P. Berrange wrote:
On Sat, Jan 15, 2011 at 02:37:33PM +0200, Alon Levy wrote:
On Fri, Jan 14, 2011 at 10:22:19AM -0700, Eric Blake wrote:
On 01/14/2011 05:24 AM, Daniel P. Berrange wrote:
On Thu, Jan 13, 2011 at 05:34:35PM -0700, Eric Blake wrote:
Assuming a hypervisor that supports multiple smartcard devices in the guest, this would be a valid XML description:
This looks pretty reasonable, but is going to require additions to the security driver code. In the SetAllLabel method of the security drivers you'll need to iterate over all smartcards.
Good catch. I'm working on that portion now. I've gone ahead and pushed 1 and 2, given that they were straight ack and were preliminary patches useful even without smartcard support.
<devices> <smartcard mode='host'/>
I guess there is some /dev/smartcard device that needs to be accessed and thus labelled here ?
I'm not sure. Alon, since -device ccid-card-emulated makes qemu use NSS to access the host's smartcard, do we need to add any particular permissions to a device file to allow qemu access to the host device (and if so, is it /dev/smartcard or something else on the host)?
The host, in the non certificates backed card case, would have some smartcard reader device, I've tested using CCID devices (the same device I'm emulating), which is a USB device, so the device file in question is /dev/bus/usb/<busnum>/<devicenum> and qemu would need permissions to access that. There are serial port connected readers I think too, so /dev/ttyS*. How would you determine the exact files? you could maybe try to find out which devices NSS accesses? I'll try to find some command (maybe certutil) or example with NSS to access this information.
Yes, how do you tell NSS which USB device to use ? QEMU/NSS will certainly *not* be allowed to scan the USB bus to find a device itself. So it seems like the XML config should let the application explicitly include a path /dev/usb/$BUS/$DEV which is explicitly passed to QEMU.
I haven't told NSS anything so far, I'll try to find out. That said, this is a minor use case from RHEV pov. /That/ said, this is of course important for upstream.
Ok, it sounds very much like NSS must be scanning for devices itself. While RHEV might not care about this, since it has a potential bearing on the XML for this use case, we need to determine what's happening asap. Regards,, Daniel