From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9Zga-0005yM-MM for qemu-devel@nongnu.org; Tue, 12 Apr 2011 05:15:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9ZgZ-00083j-QK for qemu-devel@nongnu.org; Tue, 12 Apr 2011 05:15:00 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:46206) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9ZgZ-00083Y-MJ for qemu-devel@nongnu.org; Tue, 12 Apr 2011 05:14:59 -0400 Received: by yxk8 with SMTP id 8so3102060yxk.4 for ; Tue, 12 Apr 2011 02:14:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110412081932.GC10071@redhat.com> References: <20110412075214.GA10071@redhat.com> <4DA40904.2040103@redhat.com> <20110412081932.GC10071@redhat.com> Date: Tue, 12 Apr 2011 10:14:58 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] To O_EXCL or not to O_EXCL open host_cdrom List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Kevin Wolf , qemu-devel , Markus Armbruster , Ryan Harper , Amit Shah , Christoph Hellwig On Tue, Apr 12, 2011 at 9:19 AM, Daniel P. Berrange w= rote: > On Tue, Apr 12, 2011 at 10:10:44AM +0200, Kevin Wolf wrote: >> Am 12.04.2011 09:52, schrieb Daniel P. Berrange: >> > =A0- If the -drive specification has =A0readonly=3Don (thus O_RDONLY t= o >> > =A0 =A0open(2) call) , I expect QEMU (or the kernel) to forbid the >> > =A0 =A0"eject" command on the host CDROM. This should prevent two gues= ts >> > =A0 =A0interfering seriously with each other. >> > >> > So I think using O_EXCL would be OK, in the case where the block >> > driver was =A0host_cdrom and readonly=3Doff. >> >> This would overload readonly with a completely unrelated option (should >> eject be allowed). Doesn't sound like a great idea. > > Use of the "host_cdrom" block driver enables passthrough of > commands to the host device. > > Use of "readonly" is what controls whether individual passthrough > commands are actually permitted. > > To me, "readonly" means don't allow anything that would impact > another guests view of the file/device. So forbidding 'eject' > is within scope of that IMHO. I agree with Kevin here. You're overloading the option. Today I doubt readonly will prevent the eject/lock ioctls but I haven't tes= ted. I'm becoming more convinced now that we should be using O_EXCL. Like you say, forcing raw gives us the option to share the device for reading without allowing the dangerous ioctls. Stefan