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 :|