From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuPc4-0004zZ-VK for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:23:09 -0400 Received: from [140.186.70.92] (port=51758 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuPc3-0004yo-Bc for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:23:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuPc1-0004FL-D6 for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:23:07 -0400 Received: from mail-yw0-f198.google.com ([209.85.211.198]:62776) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuPc1-0004F4-7W for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:23:05 -0400 Received: by ywh36 with SMTP id 36so1314506ywh.4 for ; Wed, 24 Mar 2010 05:23:04 -0700 (PDT) Message-ID: <4BAA0425.2030206@codemonkey.ws> Date: Wed, 24 Mar 2010 07:23:01 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt References: <4BA7C40C.2040505@codemonkey.ws> <20100323145105.GV16253@redhat.com> <4BA8D8A9.7090308@codemonkey.ws> <201003231557.19474.paul@codesourcery.com> <4BA8E6FC.9080207@codemonkey.ws> <4BA901B5.3020704@redhat.com> <4BA9A066.3070904@redhat.com> <20100324103643.GB624@redhat.com> <4BA9EC88.6000906@redhat.com> In-Reply-To: <4BA9EC88.6000906@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "libvir-list@redhat.com" , Paul Brook , qemu-devel@nongnu.org On 03/24/2010 05:42 AM, Avi Kivity wrote: > >> The filtering access part of this daemon is also not mapping well onto >> libvirt's access model, because we don't soley filter based on UID in >> libvirtd. We have it configurable based on UID, policykit, SASL, >> TLS/x509 >> already, and intend adding role based access control to further filter >> things, integrating with the existing apparmour/selinux security models. >> A qemud that filters based on UID only, gives users a side-channel to >> get >> around libvirt's access control. > > That's true. Any time you write a multiplexer these issues crop up. > Much better to stay in single process land where everything is already > taken care of. What does a multiplexer give you that making individual qemu instances discoverable doesn't give you? The later doesn't suffer from these problems. Regards, Anthony Liguori > So, at best qemud is a toy for people who are annoyed by libvirt. >