Comment 9 for bug 1350504

This is a WIP patch which, I think, mitigates the security issue here. It disallows any operations on qcow2 files which have unexpected backing file pointers. If the backing file is not the expected format (based to the path the Gluster share is mounted to and the volume id ) then operations such as clone or delete snapshot will not be allowed.

I was able to reproduce this issue by:
 - Create a volume
 - Attach to VM
 - From within the guest, write qcow2 header to the volume pointing to /etc/passwd (arbitrary file) as the backing file
 - Detach volume
 - Clone volume
 - Attach the new volume: data from the host's /etc/passwd is seen.

This patch is likely not complete and not all of the changed paths have been tested, but I wanted to float this as an idea for an interim fix to get some feedback, since the proper fix will take some time. (The patch also still contains two LOG.errors which are just for testing and should be removed, and it needs unit tests.)

Note that this does not prevent a user from corrupting their own data by doing something like writing a qcow2 header that points to a different file in their qcow2 snapshot chain for that volume (which they do have access to). It should disallow data from any other Cinder volume or file on the c-vol host from being leaked.

(Also TODO: test w/ volume migration since it does strange things with changing volume IDs)