[libvirt] [PATCH 2/2] qemu: Use secret objects to pass iSCSI passwords

[Daniel P. Berrange]

On Wed, Sep 13, 2017 at 03:24:42PM +0200, Peter Krempa wrote:
> On Wed, Sep 13, 2017 at 09:05:43 -0400, John Ferlan wrote:

> > 
> > I was thinking more about virstoragefile.c and virstoragetest.c. It's
> > easy enough to fetch the user/password-secret in
> > virStorageSourceParseBackingJSONiSCSI:
> > 
> > +    const char *user = virJSONValueObjectGetString(json, "user");
> > +    const char *secret = virJSONValueObjectGetString(json,
> > "password-secret");
> > 
> > But there's not much one can do with it as you get (for example):
> > 
> >     user = "myname"
> >     secret = "virtio-disk1-secret0"
> > 
> > but an <auth> would look like:
> > 
> >     <auth username='myname'>
> >       <secret type='iscsi' usage='mycluster_myname'/>
> >     </auth>
> > 
> > So to a degree it's not testable to build the XML as virstoragetest
> > does. Sine the secret can be built up using the disk alias, it's perhaps
> > not even worth storing away.
> 
> Yes, the field is rather useless. I'm even surprised that it's recorded
> into the backing file string. It may be used as a notification that
> authentication is required, but without actually adding the secret with
> correct name, the thing won't work anyways.

That is a bug in QEMU - we should not be recording the 'password-secret"
field in the backing store that is embedded in the qcow2 file. The IDs
of the secret objects are only meaningful for the current invokation of
QEMU / qemu-img / etc.

So if a backing store needs a password, then libvirt needs to explicitly
set the password-secret for the backing store, recursively


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|