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

[Jamie Lokier <jamie@shareable.org>]

Ian Jackson wrote:
> > 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.

Also, the point about qcow2 metadata.  If you have multiple QEMU
instances using the same qcow2 image, it is not acceptable to have
them both trying to write qcow2 metadata - unless they are interlocked
in some way (as fas as I know they're not).

Personally I use 'chattr +i' on such files.  But it's not very
userspace friendy, e.g. for VM management scripts run by other people.
You need root access to do 'chattr +i'.

> 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.

I would think for environments where a single image is launched many
times, e.g. 'start OS foo and tell it to run my test program', it's
important that the *file* be open read-only regardless of what the
guest can see.

In that usage, -snapshot or creating an explicit qcow2 derived file
would be appropriate.  But it's still important that the base file is
opened read-only, and that 'commit' to it is forbidden.

-- Jamie