Features/VirtPolicyKit

= Virt Manager PolicyKit integration =

Summary
The virt-manager application currently runs as root when managing a local hypervisor. It uses console-helper to authentication from a desktop session. Running GTK applications as root is evil. By integrating with PolicyKit it will be possible to run virt-manager as a regular user

Owner

 * Name: DanielBerrange

Current status

 * Targeted release:  Fedora 9
 * Last updated: 2008-03-15
 * Percentage of completion: 100%

Detailed Description
The virt-manager application currently runs as root when managing a local hypervisor. It uses console-helper to authentication from a desktop session. Running GTK applications as root is evil. virt-manager can also be used to remotely manage guests on another server, in which case running as root is even less desirable. By integrating with PolicyKit it will be possible to run virt-manager as a regular user, while securely authenticating against a local libvirt daemon. The storage management APIs will enable virt-manager to create new guests will running as non-root.

Benefit to Fedora
PolicyKit is replacing console-helper as the defacto mechanism for local management applications to gain privileges. Virt-manager should take full advantage of PolicyKit to run unprivileged in the local desktop session.

Scope

 * Add PolicyKit authentication mechanism to libvirt daemon (in rawhide in libvirt 0.4.0)
 * Extend virt-manager to talk to PolicyKit GNOME helper via DBus to authenticate (merged upstream, pending next virt-manager release)

Test Plan

 * Install a Fedora 9 instance with either KVM or Xen hypervisors enabled
 * Run virt-manager from a GNOME desktop session
 * Attempt to connect to the local hypervisor using virt-manager
 * Enter any authentication credentials requested by PolicyKit
 * Observe that virt-manager is running as non-root, and managing the local hypervisor

User Experience
The virt-manager application is running with normal user privileges. It thus has full integration with the local desktop session. They can configure PolicyKit to require no-password, or the user password (sudo style), or the root password (console-helper style) when attaching virt-manager to the local hypervisor.

Dependencies
This is an incremental step from the proposed feature on authentication:


 * Virtualization Authentication

Contingency Plan
Best case contingency:


 * Simply use the libvirt SASL support with either Kerberos, or username/password for authetication

Worse case contingency:


 * Continue to use console-helper as with Fedora 8 and earlier

Documentation
There is no special setup required for use of PolicyKit authentication with virt-manager/libvirt. If the desktop session supports PolicyKit it will automatically be enabled.

The libvirt website provides some notes on how to turn PolicyKit authentication on/off


 * http://libvirt.org/auth.html

Though it is enabled by default on Fedora and there is no particular need to turn it off.

Release Notes
It is now possible to run virt-manager as an unprivileged user and manage VMs running on the local machine. When starting virt-manager from the Applications menu select the 'Run unprivileged' option. At the time it attempts to connect to a local hypervisor it will automatically display a PolicyKit authentication dialog to obtain valid credentials. Once authentication it is possible to start/stop/configure virtual machines as needed. It is not yet possible to create new virtual machines when running unprivileged using PolicyKit auth. This ability will be added at a later date, once storage management capabilities are fully integrated with virt-manager.