Bug 472727 - Allow read-write access without policykit
Allow read-write access without policykit
Status: CLOSED UPSTREAM
Product: Virtualization Tools
Classification: Community
Component: virt-manager (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Berrange
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-24 01:37 EST by Michael Marineau
Modified: 2010-03-16 13:16 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-26 11:20:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
virt-manager-0.6.0-readwrite-without-policykit.patch (2.04 KB, patch)
2008-11-24 01:37 EST, Michael Marineau
no flags Details | Diff
virt-manager-read-only-fallback.patch (2.91 KB, patch)
2008-12-01 22:12 EST, Michael Marineau
no flags Details | Diff

  None (edit)
Description Michael Marineau 2008-11-24 01:37:56 EST
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?
Comment 1 Michael Marineau 2008-12-01 22:12:10 EST
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.
Comment 2 Cole Robinson 2009-01-23 15:33:41 EST
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.
Comment 3 Daniel Berrange 2009-01-23 15:44:29 EST
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.
Comment 4 Cole Robinson 2009-01-26 11:20:05 EST
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!

Note You need to log in before you can comment on or make changes to this bug.