From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuPmw-0008Vm-Gw for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:34:22 -0400 Received: from [140.186.70.92] (port=37798 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuPmm-0008KR-Ih for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:34:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuPkx-0005hR-NJ for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:32:23 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:43922) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuPkx-0005hJ-Gt for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:32:19 -0400 Received: by pwi9 with SMTP id 9so4828024pwi.4 for ; Wed, 24 Mar 2010 05:32:18 -0700 (PDT) Message-ID: <4BAA064F.6010306@codemonkey.ws> Date: Wed, 24 Mar 2010 07:32:15 -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> <4BAA0425.2030206@codemonkey.ws> <4BAA05BD.1040708@redhat.com> In-Reply-To: <4BAA05BD.1040708@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 07:29 AM, Avi Kivity wrote: > 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. Deleting it on atexit combined with flushing the whole directory at startup is a pretty reasonable solution to this (which is ultimately how the entirety of /var/run behaves). If you're really paranoid, you can fork() a helper with a shared pipe to implement unlink on close. Regards, Anthony Liguori > Maybe we want a O_UNLINK_ON_CLOSE for unix domain sockets - but no, > that's not implementable. >