[libvirt] [PATCH 01/20] Secret manipulation step 1: Public API

Daniel Veillard veillard at redhat.com
Wed Aug 19 13:06:20 UTC 2009


On Wed, Aug 19, 2009 at 10:34:38AM +0100, Daniel P. Berrange wrote:
> On Wed, Aug 19, 2009 at 11:21:58AM +0200, Daniel Veillard wrote:
> > On Sun, Aug 16, 2009 at 10:47:54PM +0200, Miloslav Trma?? wrote:
> > > This patch adds a "secret" as a separately managed object, using a
> > > special-purpose API to transfer the secret values between nodes and
> > > libvirt users.
> > 
> >   Okay, interesting...
> > 
> > > Rather than add explicit accessors for attributes of secrets, and
> > > hard-code the "secrets are related to storage volumes" association in
> > > the API, the API uses XML to manipulate the association as well as
> > > other attributes, similarly to other areas of libvirt.
> > > 
> > > The user can set attributes of the secret using XML, e.g.
> > >   <secret ephemeral='no' private='yes'>
> > >     <uuid>b8eecf55-798e-4db7-b2dd-025b0cf08a36</uuid>
> > >     <volume>/var/lib/libvirt/images/mail.img</volume>
> > >     <description>LUKS passphrase for our mail server</description>
> > >   </secret>
> > > If <uuid/> is not specified, it is chosen automatically.
> > 
> >   Should secret always be tied to volumes. The API is generic enough
> > that we should make sure we can use this later to get priviledged
> > access to other resources, though right now I don't have a good
> > example in mind.
> 
> [snip]
> 
> > > - use "unsigned char *" for secret value
> > 
> >   fine, assuming 0 terninated. though this may not work with everything
> > but since we need to import/export to XML, unless uuencoding the value
> > we won't be able to embed something which is not part of XML character
> > range (#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
> > [#x10000-#x10FFFF]) unicode code points.
> 
> No need to worry about this, since we're not going to include the secret
> values in the XML.

  Whoops, right it's not supposed to show up there. Okay this is a
  non-issue :-)


> Yes, the secret value should never be exposed in the XML anyway - that's
> the primary goal of having this separate API. The secret should only ever
> be exposed by these GetValue/SetValue APIs, and never logged in any of
> the libvirt internal code paths.

  Yes makes sense,

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/




More information about the libvir-list mailing list