Re: [Qemu-devel] [PATCH] HMP: snapshot_blkdev can not consider //root/sn1 and /root/sn1 as the same file

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]

On 01/02/2014 01:55 AM, Stefan Hajnoczi wrote:

> Okay, I think we got side-tracked worrying about identifying identical
> files.  The problem in your example is more fundamental.
> 
> Here is what should have happened:
> 
>   (qemu) snapshot_blkdev drive-scsi0-0-0  /mnt/dir2/sn1
>   Could not create '/mnt/dir2/sn1': File exists
> 
> The file was previously created with the name /mnt/dir1/sn1.  Running
> snapshot_blkdev with /mnt/dir2/sn1 clobbers the file in your example.
> This is bad because it corrupts the backing chain.
> 
> If QEMU uses O_CREAT | O_EXCL open(2) flags then creating the snapshot
> file fails and the user will not mistakingly overwrite sn1.
> 
> However, QEMU does not use O_EXCL to create image files anywhere today
> (qemu-img or QEMU monitor commands).  Returning an error is not
> backwards-compatible since existing users might rely on clobbering files
> (there are safe cases where it can be useful).

In fact, libvirt _requires_ that you clobber existing image files - when
libvirt drives qemu with SELinux labelling enabled, then qemu cannot
create files, but can only open already existing files that have already
been labelled.  So libvirt would need a way to avoid O_EXCL, even if you
add it and make it default (and if you change the default to O_EXCL, you
also need to provide a way to probe for the new switch that can bypass
that new default).

> 
> We could add an option to commands that create files but I'm not sure if
> it's worth the effort since human users who are most at risk probably
> won't provide this new option...

Changing to be safe by default and requiring a new option to allow reuse
of existing files might be okay; but it will be backwards incompatible.
 Keeping existing behavior and requiring a new option to turn on O_EXCL
for safety is back-compat friendly, but is the very situation where
users aren't going to know they need to use the new option, so you've
gained no safety.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]