From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KOy8r-00082c-EA for qemu-devel@nongnu.org; Fri, 01 Aug 2008 13:10:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KOy8o-0007yV-P7 for qemu-devel@nongnu.org; Fri, 01 Aug 2008 13:10:11 -0400 Received: from [199.232.76.173] (port=54713 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOy8n-0007xa-V5 for qemu-devel@nongnu.org; Fri, 01 Aug 2008 13:10:10 -0400 Received: from wr-out-0506.google.com ([64.233.184.233]:58503) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KOy8n-0001an-0t for qemu-devel@nongnu.org; Fri, 01 Aug 2008 13:10:09 -0400 Received: by wr-out-0506.google.com with SMTP id c46so896907wra.18 for ; Fri, 01 Aug 2008 10:10:02 -0700 (PDT) Message-ID: <48934347.7040102@codemonkey.ws> Date: Fri, 01 Aug 2008 12:09:27 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] PATCH: Control over drive open modes for backing file References: <20080731113120.GJ23888@redhat.com> <489203C9.1040607@codemonkey.ws> <20080801091809.GJ23993@redhat.com> <4893222A.6050101@codemonkey.ws> <18579.15930.393041.733173@mariner.uk.xensource.com> In-Reply-To: <18579.15930.393041.733173@mariner.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "qemu-devel@nongnu.org" 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. > > >