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/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list