Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt

[Avi Kivity <avi@redhat.com>]

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