Comment 15 for bug 1350504

Comments on Tristan's description:

I was focusing on Cinder-volume host data leak rather than compute host -- I'm not sure if a compute host leak is possible yet, but it might be. (Write the bad header, detach, reattach it w/o any other operations? I'll need to test this.)

The description paragraph there would result in leaking a file on the cinder-volume host, not the compute host.

We also need to note as a workaround that setting glusterfs_qcow2_volumes=True in cinder.conf prevents this issue for any volumes created after that option is set. (This is False by default.)

> Does the malicious volume allow write operation as well ?
I can't currently come up with a way that it would. This would be possible if you could inject a bad qcow2 header into a snapshot file, but since it's only possible for the base volume file, I can't think of any sequence of events that would allow this.

We only do two types of writes based on qcow2 backing file headers:
 1) commits of snapshot files down to the base volume file or another snapshot file
 2) pulls of base volume files up into a snapshot file.

> Is the leaked through libvirt/kvm context ?
Need to look at the above scenario about compute host leaks and get more info on this point.
The one I described was in the cinder-volume context, which in most deployments is running as a "cinder" user.

> Should Eric Harney be added to the reporter list ?
Probably not, Duncan pointed this out to me elsewhere, I just filed the bug to get things moving.

> From the VMT point of view, UUID guessing based attacks are not considered a practical vulnerability...
I don't think that even successful UUID guessing would buy you anything with the proposed patch. It restricts data access to the volume identified by the UUID which you already know and already have access to.