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/