From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50537 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q6kjf-0005om-II for qemu-devel@nongnu.org; Mon, 04 Apr 2011 10:26:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q6kjZ-0001N8-3Z for qemu-devel@nongnu.org; Mon, 04 Apr 2011 10:26:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8737) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q6kjY-0001Mx-Pg for qemu-devel@nongnu.org; Mon, 04 Apr 2011 10:26:25 -0400 Date: Mon, 4 Apr 2011 15:26:12 +0100 From: "Daniel P. Berrange" Subject: Re: [libvirt] [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change Message-ID: <20110404142612.GD13616@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4D99D378.8030206@us.ibm.com> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Stefan Hajnoczi , Juan Quintela , libvir-list@redhat.com, Stefan Hajnoczi , qemu-devel@nongnu.org, Blue Swirl 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. > But with libvirt today, when you launch a guest, your security > context doesn't matter and there's no way you can control what > context the guest gets. libvirt is essentially creating it's own > authorization mechanism. Supporting ACLs goes much further down > that path. > > >>How much of a leap would it be to spawn a guest with the credentials > >>of the user that created/defined it? Or better yet, to let the user > >>be specified in the XML. > >That's a completely independent RFE which won't fix this issue in > >the general case. > > I think it really does. Nope it doesn't. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|