Re: [libvirt] backing file chains, -blockdev, and storage file autodetection

On Thu, 2020-01-09 at 14:34 +0000, Daniel P. Berrangé wrote: > > IIUC there are three scenarios at play here > > 1. qcow2 file, first level raw backing > 2. qcow2 file, first level qcow2 backing, no backing > 3. qcow2 file, first level qcow2 backing, with second level backing > > Historically with the SELinux driver, if no backing_fmt is set, > then we blindly assume that scenario (1) is in effect. > > We cannot tell QEMU that we treated it as scenario (1) though, > so QEMU will still probe format and potentially open the > first level backing as qcow2 still. > > IOW, despite our SELinux & QEMU driver assumption for scenario (1), > scenario (2) would still suceed in the past. Scenario (3) would > always have failed, because SELinux won't have labelled the second > level backing. But it only failed with SELinux, right? Not every distro is mandating SELinux usage with libvirt. SUSE distros don't, for example.

> Essentially scenario (2) worked by accident, not design, but > IIUC we have not been warning users about this. > > With new libvirt and -blockdev we still assume the backing_fmt > is raw if not set in the SELinux driver, but we now have the > ability to tell QEMU about our assumption via -blockdev. As > such we've not ensured scenario (2) fails. > > > Users who were silently relying on scenario (2) are now broken > and have three options IIUC > > - Run qemu-img rebase to set the backing_fmt > > or > > - Update the guest XML to set the <backingStore> format value > > or > > - Update the /etc/libvirt/qemu.conf to set capability_filters > to disable "blockdev" I wasn't aware of this option, thanks. I'd actually looked for a way to revert libvirt's behavior to what it did in previous versions.

> Always assuming the format is raw certainly avoids the security > danger, but is unhelpful to users who relied on scenario (2). > > I'm inclined to say we should make scenario (2)/(3) into a hard > error. Only allow scenario (1) to run normally. > > ie, we should probe the disk format for the backing file, and > if it is *not* raw, then report an immediate error, with the > error message pointing to the kbase page explaining how to > fix this. This will help the 99% common case identify the > fix more quickly, with no obvious downside that I see. Sounds good. I'd appreciate mention of the capability_filters option on the kbase page.