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

[Avi Kivity]

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