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

[Anthony Liguori <anthony@codemonkey.ws>]

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.
>