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


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