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/