[libvirt] [PATCHv3 1/5] smartcard: add XML support for <smartcard> device
Alon Levy
alevy at redhat.com
Wed Jan 26 18:09:28 UTC 2011
On Wed, Jan 26, 2011 at 04:03:44PM +0000, Daniel P. Berrange wrote:
> On Wed, Jan 26, 2011 at 05:49:36PM +0200, Alon Levy wrote:
> > On Wed, Jan 26, 2011 at 12:25:06PM +0000, Daniel P. Berrange wrote:
> > > On Tue, Jan 25, 2011 at 05:36:54PM -0700, Eric Blake wrote:
> > > > + <dl>
> > > > + <dt><code>mode='host'</code></dt>
> > > > + <dd>The simplest operation, where the hypervisor relays all
> > > > + requests from the guest into direct access to the host's
> > > > + smartcard via NSS. No other attributes or sub-elements are
> > > > + required. However, in cases where extra permissions must be
> > > > + granted to the hypervisor to access the host's smartcard device,
> > > > + an optional <code><source
> > > > + dev='/path/to/smartcard'/></code> element is supported.
> > > > + Also, see below about the use of an
> > > > + optional <code><address></code> sub-element.</dd>
> > >
> > > Based on the mail about pcscd, we don't want a device path here
> > > after all.
> > >
> > > > + <dt><code>mode='host-certificates'</code></dt>
> > > > + <dd>Rather than requiring a smartcard to be plugged into the
> > > > + host, it is possible to provide three files residing on the host
> > > > + and containing NSS certificates. These certificates can be
> > > > + generated via the command <code>certutil -d /etc/pki/nssdb -x -t
> > > > + CT,CT,CT -S -s CN=cert1 -n cert1</code>, and the resulting three
> > > > + files must be supplied as the content of each of
> > > > + three <code><certificate></code> sub-elements. An
> > > > + additional sub-element <code><database></code> can specify
> > > > + an additional file to use as the database.</dd>
> > >
> > > What does the 'database' do ? This concept is somewhat specific
> > > to the NSS library afaict - other crypto libraries don't have a
> > > database like this.
> > >
> > > Should we also have 'database' for the 'host' mode if we need one ?
> >
> > Yes, without it the usage of certificates is limited to the default certificate
> > store, and if anyone wants to run multiple qemu's with different certificates they
> > may want to put them into different dbs. It is currently (well, there is only
> > one backend currently, speaking tech wise certificates and emulated both use
> > NSS) NSS specific, but I think winscard (started investigating that) also has some
> > relevant concept. True that it might not fit. Still I think it's more useful with it.
>
> What does QEMU/NSS do with the certificate database ? Is it a readonly
> database, or does QEMU/NSS also write to this ? I'm wondering why we
> need to specify x509 certificates, as well as the certificate database ?
The cert1/cert2/cert3 names are only internal references in that db, they
don't have a global meaning (i.e. it isn't filenames or any other type of uri).
>
> Daniel
More information about the libvir-list
mailing list