From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KOy9Z-0000Y1-40 for qemu-devel@nongnu.org; Fri, 01 Aug 2008 13:10:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KOy9X-0000Us-47 for qemu-devel@nongnu.org; Fri, 01 Aug 2008 13:10:56 -0400 Received: from [199.232.76.173] (port=34329 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOy9W-0000Ud-UC for qemu-devel@nongnu.org; Fri, 01 Aug 2008 13:10:54 -0400 Received: from mail2.shareable.org ([80.68.89.115]:48432) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KOy9W-0001ln-Ng for qemu-devel@nongnu.org; Fri, 01 Aug 2008 13:10:54 -0400 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1KOy9V-0006ae-7O for qemu-devel@nongnu.org; Fri, 01 Aug 2008 18:10:53 +0100 Date: Fri, 1 Aug 2008 18:10:53 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] PATCH: Control over drive open modes for backing file Message-ID: <20080801171053.GB25063@shareable.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18579.15930.393041.733173@mariner.uk.xensource.com> 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: > > 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