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

[Daniel P. Berrange]

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.

[snip]

> > +int                     virSecretSetValue       (virSecretPtr secret,
> > +                                                 const unsigned char *value,
> > +                                                 size_t value_size);
> > +unsigned char *         virSecretGetValue       (virSecretPtr secret,
> > +                                                 size_t *value_size);
> 
>   Ah, so we aren't relying on 0 termination, but in that case the value
> need to be uuencoded in the XML, and that should be made clear in the
> API description. Actually not having the secret completely in the clear
> in the XML dump sounds like a good idea.

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.


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|