[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] PATCH: Control over drive open modes for backing file
Date: Fri, 01 Aug 2008 12:09:27 -0500
User-agent: Thunderbird (X11/20080501)

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)

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.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]