[libvirt] [PATCH] Default to qemu:///system if accessible

Soren Hansen soren at ubuntu.com
Fri Sep 3 20:38:26 UTC 2010


On 03-09-2010 16:08, Daniel P. Berrange wrote:
>> If no uri is passed to one of the virConnectOpen-ish calls, libvirt
>> attempts to autoprobe a sensible URI. Part of the current logic checks
>> for getuid() > 0, and if that check is succesful, a libvirtd daemon is
>> spawned. This patch replaces this check with a call to
>> access(LIBVIRTD_PRIV_UNIX_SOCKET, W_OK) so that users with access to the
>> qemu:///system UNIX socket connect to that one by default instead of
>> spawning a new libvirtd daemon.
> NACK, I don't think we should be changing this. If the user
> is unprivileged, it should always default to the unprivileged
> libvirtd, regardless of whether they are also authorized to
> connect to the privileged libvirtd (via socket permissions or
> policykit, or kerberos). If the unprivileged user still wants
> the privileged libvirtd, they should given an explicit URI.

Hm... I didn't think this was going to be controversial :)

I firmly believe that if a user has access to the privileged libvirt
daemon, that's the one he'll want to interact with in all but
extraordinary cases. I consider it very analogous to how virt-manager
doesn't even offer usermode networking if you're connected to
qemu:///system, since if you aren't stuck with usermode networking,
there's no reason to use it (other than to prove this statement wrong).

Ubuntu has carried patches for this for virsh, virt-manager, and
virt-viewer for a while now (at least a year and a half). I'm not sure
if they've been submitted here (or to et-mgmt-tools) before (and if not,
why not), but that's the lay of the land, and I've had nothing but good
feedback on it. Now I just wanted to fix it properly (directly in
libvirt) and get it upstream. It's certainly saved me a lot of typing.

-- 
Soren Hansen
Ubuntu Developer
http://www.ubuntu.com/




More information about the libvir-list mailing list