Re: [Qemu-devel] PATCH: Control over drive open modes for backing file

[Anthony Liguori <anthony@codemonkey.ws>]

Ian Jackson wrote:
> Anthony Liguori writes ("Re: [Qemu-devel] PATCH: Control over drive open modes for backing file"):
>   
>> Right, but my point is that ,mode=ro does not have to force QEMU to open 
>> the file O_RDONLY.  It simply needs to prevent writes from happening.
>>     
>
> Well, yes, but actually it's probably most reliable to do it that way.
> Given that this is a security feature we want to avoid accidentally
> `missing' a case.  So we should definitely open the underlying file(s)
> O_RDONLY.
>   

That is an implementation detail, and should be dependent on the 
underlying file format.  For instance, I completely agree that this 
should be the behaviour for raw images.  I don't agree that this should 
be the behaviour with qcow2 though.

FWIW, this isn't a major security improvement.  It's pretty darn easy to 
audit the single calling location where a file can be written to :-)

> If we do that then the guest definitely won't be able to write as if
> it manages to persuade qemu to try qemu will just get an error.  This
> is fine I think, if we can expose the read-only status to the guest.
>
>   
>> But it's important to be able to expose this property to the guest, so 
>> ,mode=ro should not be allowed for disks that do not support exposing 
>> their read-only-ness to the guest.
>>     
>
> I agree that it would be an unusual thing to do, to expose a ro disk
> in a way that doesn't support advertising the ro flag.  But I think it
> should still be possible perhaps with some kind of force option.
>   

There's no good reason to do this and it's just going to result in 
confusing users.  You can approximate the same functionality by using 
,snapshot=on while giving the guest predictable behaviour.

Regards,

Anthony Liguori

> Ian.
>
>
>