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

On Wed, Jan 08, 2020 at 13:34:14 +0000, Martin Wilck wrote: I'm sorry for causing this. I'm also sorry for going to sound too dismissive later on. This is a good sounding idea but mostly pointless when attempting to pull off. If we'd add notes in the documentation, most people wouldn't read them until stuff breaks. Similarly for putting warnings into the code. They end up in the log file and not many people even bother to read them. The only recourse would be: "we told you so a year ago in this document you didn't read". The end result would be the same. You are right in cases when the backing image is always a backing image. That can't be guaranteed though because the VM may use the image as the only image in raw mode. Then when an overlay is created the image may already be compromised. Obviously this requires the permission to do the overlay, which can arguably not be granted. In general though this scenario is possible. In libvirt we already always record the image format when creating the overlay for many years now. No this is impossible to do without compromising qemu or misconfiguring the VM, so you are right. Well, for distros using selinux this attack is mitigated by selinux usage. That was also the reason why "assuming raw" was good enough. It was also 'good enough' because there wasn't any other option. It additionally created a whole lot of users which were already bitten by this many years ago and now use the format correctly since we'd not allow access otherwise when selinux is used. The option to allow autodetection was removed some time ago with the rationale that it's not worth even allowing reverting to an insecure configuration. While this will cause a disruption during upgrade, users will need to modify the custom scripts. Unfortunately that would have to hapen in one way or another anyways. Ideally users should take advantage libvirt APIs to create overlays since they always record the image format. Also I'm not really sold on the idea of matching qcow2 in the image name. It's just another bit of metadata, you can record it properly in the overlay. (*) Additionally there's a lot of wrong documentation on the internet which doesn't call for specifying the backing format. Thus there's always a group of things that will break. Again, I'm sorry for sounding too dismissive, but in one way or another I don't think this was avoidable. It could be partially mitigated if I remembered to force the error when backing store format is missing in 5.10. I added it just recently. Possibly the search engines didn't pick it up. * I will need to think about this for a bit first.