[libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Avi Kivity
avi at redhat.com
Wed Mar 24 12:29:49 UTC 2010
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
More information about the libvir-list
mailing list