From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOd5q-0004nB-5x for qemu-devel@nongnu.org; Mon, 23 May 2011 17:55:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOd5p-0005Mu-9K for qemu-devel@nongnu.org; Mon, 23 May 2011 17:55:18 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:42146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOd5p-0005Mo-71 for qemu-devel@nongnu.org; Mon, 23 May 2011 17:55:17 -0400 Received: by yxk8 with SMTP id 8so2759717yxk.4 for ; Mon, 23 May 2011 14:55:16 -0700 (PDT) Message-ID: <4DDAD7C1.80708@codemonkey.ws> Date: Mon, 23 May 2011 16:55:13 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4DD6B777.9020800@us.ibm.com> <4DD6C424.1020104@codemonkey.ws> <4DDA6EFA.9040501@redhat.com> <4DDA83C2.5060104@redhat.com> In-Reply-To: <4DDA83C2.5060104@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Add support for fd: protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: aliguori@us.ibm.com, Corey Bryant , Markus Armbruster , qemu-devel@nongnu.org, Blue Swirl , Tyler C Hicks On 05/23/2011 10:56 AM, Kevin Wolf wrote: > Am 23.05.2011 17:24, schrieb Markus Armbruster: >> Kevin Wolf writes: >> >> An fd: protocol can't easily support reopen. So fail it. This doesn't >> break any existing usage. It's just a restriction on the new protocol. >> Restrictions can render the new protocol useless in practice, but we're >> not "breaking qemu without libvirt" there. >> >> Perhaps we can make relax the restriction on some system by avoiding the >> reopen in a system-dependent way. > > Right, you only get the regression once libvirt starts using it (or even > worse, qemu itself, like Blue Swirl suggested). Doesn't make it much better. libvirt already has the problem you describe. QEMU is designed assuming that we can access whatever resources the invoking user can. That's how our UI is constructed. But libvirt chooses to invoke QEMU in such a way that the actual QEMU process does not have the same rights as the invoking user. In fact, the context is entirely different. That means that to get isolation, libvirt has to understand what QEMU does for each operation and then do some magic behind the scenes to make it all work. This is not different really. 'commit' could require magic in libvirt anyway if libvirt was smart enough to mark the backing file with read-only rights. libvirt already has to parse image file formats to figure out backing files so it can set the permissions right. Regards, Anthony Liguori > Kevin >