Comment 57 for bug 2059809

Revision history for this message
Martin Kaesberger (mkaesberger) wrote : Re: Arbitrary file access through QCOW2 external data file

Jeremy Stanley: On Debian/Ubuntu it is prevented by apparmor because the path is prepended, on Rocky Linux 9 the patch isn't enough. "Apr 10 14:56:04 localhost.localdomain cinder-volume[2918]: ERROR cinder.volume.manager Stderr: "qemu-img: Could not open '/opt/stack/data/cinder/conversion/image_fetch_26c18b43-a3df-4696-a9fc-fb534da7edba_45n7q3wclocalhost.localdomain@lvmdriver-1': Could not open 'file-1.raw': No such file or directory\n"" ~> the graph is evaluated, but I did not create the file.
The VMDK doesn't work and the path is prepended. I have no idea, where this is coming from. Maybe it depends on the flags qemu was compiled with.

Brian Rosmaita:
1. Yes, the NBD server is just for convenience. An eye on the output is faster than reloading the file.
2. You can place any driver as childen of the quorum. [1] The only requirement is, that the file/driver must be writeable, but I wouldn't be suprised if something like blkdebug might work around that.
3. If it's placed in the data file field, this is correct. I have not yet tested this extensively for the backing file in Qcow2 and extents in VMDK

[1] https://qemu-project.gitlab.io/qemu/interop/qemu-qmp-ref.html ~> search for "Drivers that are supported in block device operations."