[libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori
anthony at codemonkey.ws
Wed Mar 24 12:32:15 UTC 2010
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.
>
More information about the libvir-list
mailing list