[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
Date: Wed, 24 Mar 2010 14:29:49 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]