From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37304 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q6l0R-0002ak-2g for qemu-devel@nongnu.org; Mon, 04 Apr 2011 10:43:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q6l0O-0005WO-3q for qemu-devel@nongnu.org; Mon, 04 Apr 2011 10:43:48 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:37495) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q6l0O-0005WI-1Q for qemu-devel@nongnu.org; Mon, 04 Apr 2011 10:43:48 -0400 Received: by ywl41 with SMTP id 41so2701425ywl.4 for ; Mon, 04 Apr 2011 07:43:47 -0700 (PDT) Message-ID: <4D99D920.1040800@codemonkey.ws> Date: Mon, 04 Apr 2011 09:43:44 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [libvirt] [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change References: <1301425482-8722-1-git-send-email-stefanha@linux.vnet.ibm.com> <1301425482-8722-4-git-send-email-stefanha@linux.vnet.ibm.com> <20110404104753.GX13616@redhat.com> <4D99C162.7060706@us.ibm.com> <20110404131639.GB13616@redhat.com> <4D99D378.8030206@us.ibm.com> <20110404142612.GD13616@redhat.com> In-Reply-To: <20110404142612.GD13616@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Kevin Wolf , Anthony Liguori , Stefan Hajnoczi , Juan Quintela , libvir-list@redhat.com, Stefan Hajnoczi , qemu-devel@nongnu.org, Blue Swirl On 04/04/2011 09:26 AM, Daniel P. Berrange wrote: > On Mon, Apr 04, 2011 at 09:19:36AM -0500, Anthony Liguori wrote: >> On 04/04/2011 08:16 AM, Daniel P. Berrange wrote: >>> That doesn't really have any impact. If a desktop user is logged >>> in, udev may change the ownership to match that user, but if they >>> aren't, then udev may reset it to root:disk. Either way, QEMU >>> may loose permissions to the disk. >> Then if you create a guest without being in the 'disk' group, it'll >> fail. That's pretty expected AFAICT. > We don't *ever* want to put QEMU in the 'disk' group because > that gives it access to any disk on the system in general. If that's what the user wants to do, what's the problem with doing it? Setting the global user/group is not enough because just because you have one VM that you want in disk doesn't mean you want all of them in disk. And to be clear, if you could do this today, there wouldn't be a problem here in terms of QEMU just reopening the file. Regards, Anthony Liguori Regards, Anthony Liguori