From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuPr6-0001Lj-ER for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:38:40 -0400 Received: from [140.186.70.92] (port=37798 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuPnK-0008KR-BZ for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:34:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuPif-0005L8-86 for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:29:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14278) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuPie-0005L3-UP for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:29:57 -0400 Message-ID: <4BAA05BD.1040708@redhat.com> Date: Wed, 24 Mar 2010 14:29:49 +0200 From: Avi Kivity 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> <4BAA0425.2030206@codemonkey.ws> In-Reply-To: <4BAA0425.2030206@codemonkey.ws> 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: Anthony Liguori Cc: "libvir-list@redhat.com" , Paul Brook , qemu-devel@nongnu.org On 03/24/2010 02:23 PM, Anthony Liguori wrote: > 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. > You don't get a directory filled with a zillion socket files pointing at dead guests. Agree that's a poor return on investment. Maybe we want a O_UNLINK_ON_CLOSE for unix domain sockets - but no, that's not implementable. -- error compiling committee.c: too many arguments to function