Created attachment 324455 [details] virt-manager-0.6.0-readwrite-without-policykit.patch For local connections when libvirt is installed without policykit support virt-manager always connects in read-only mode even though access is actually controlled by the socket permissions and doesn't have much to do with policykit at all. It seems reasonable that if libvirt is perfectly happy without policykit virt-manager ought to be as well. Since the defined location of the local unix socket appears to be tucked away inside libvirt and is not made available in the python api there doesn't appear to be a good way test whether read/write access is allowed without attempting a read/write connection and seeing if it fails. I've put together a crude patch that takes this approach and will attempt to connect with read/write access and fall back on read-only if that fails. The behavior when policykit is around is unchanged and it will only attempt to connect once as it did before. Any thoughts on the best way of going about this?
Created attachment 325328 [details] virt-manager-read-only-fallback.patch Here is a new version of the patch that doesn't suck and was created against the current tip. This patch removes the read-only guess based on if one of the policykit files happen to exist in the expected location. Instead it will normally default to read-write but fall back to a read-only connection. This fall-back applies to all connections.
Danpb, this patch looks reasonable to me, any objections? Seems to me like trying to connect readonly if PolicyKit isn't found would only confuse users anyways. They would either expect full access or none at all.
My only concern would be whether it works correctly on a libvirt install using Xen, plus the setuid libvirt_proxy daemon (eg, RHEL-5 Xen hosts). Seems like the proposed patch would do the right thing, but worth double-checking just to be sure. ie, it should automatically make a read-only Xen connection to the Xen proxy, with no error messages being seen by the user.
Great! I tested this on RHEL5 with a new enough libvirt to provide the openAuth call, seems to work as expected: Regular user falls through to R/O connection Root user gets full R/W access No errors were thrown in the process. So I've committed this now: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/9d7b7b42bcb8 Thanks for the patch!