Bug 625115

Summary: cannot run virt-manager as regular user in a VNC session
Product: Red Hat Enterprise Linux 6 Reporter: Jeff Bastian <jbastian>
Component: libvirtAssignee: Cole Robinson <crobinso>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: berrange, dallan, dyuan, eblake, ikke, lfarkas, myllynen, mzhan, rdassen, rwu, sputhenp, weizhan, whuang, xen-maint, yoyzhang, zpeng
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: libvirt-0.9.10-1.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 06:24:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Allow polkit auth for SSH and VNC users none

Description Jeff Bastian 2010-08-18 16:01:51 UTC
Description of problem:
I'm running a VNC session on a remote RHEL 6 Beta system, and if I try to start virt-manager as a regular user, it gives me an error:
    Unable to open a connection to the libvirt management daemon.
    Libvirt URI is: qemu:///system
    Verify that:
      - The 'libvirtd' daemon has been started

libvirtd is running:
    $ pgrep -l libvirt
    7868 libvirtd

If I expand the Details section, it shows a Python traceback indicating an authentication problem.
    Unable to open connection to hypervisor URI 'qemu:///system':
    authentication failed
    Traceback (most recent call last):
      File "/usr/share/virt-manager/virtManager/connection.py", line 992, in _try_open
        None], flags)
      File "/usr/lib64/python2.6/site-packages/libvirt.py", line 111, in openAuth
        if ret is None:raise libvirtError('virConnectOpenAuth() failed')
      libvirtError: authentication failed

Starting virt-manager via sudo works fine.

virt-manager should ask for a password if it fails to authenticate instead of giving a misleading error message.

Version-Release number of selected component (if applicable):
virt-manager-0.8.4-7.el6.noarch
libvirt-0.8.1-20.el6.x86_64
polkit-0.96-2.el6.x86_64
ConsoleKit-0.4.1-3.el6.x86_64

How reproducible:
every time

Steps to Reproduce:
1. as a regular user on a RHEL 6 system:
      vncserver -geometry 1680x1050 -depth 24
2. from another system:
      vncviewer -via rhel6-hostname rhel6-hostname:1
3. in the VNC session
      virt-manager
  
Actual results:
virt-manager prints an error asking if libvirtd is running 

Expected results:
virt-manager asks for a password or otherwise starts successfully

Additional info:
This has also been reported in Fedora bug 579579.

Comment 1 Jeff Bastian 2010-08-18 16:12:08 UTC
polkit is running in my VNC session and trying to start a new agent complains that it's already running:


$ ps auxwww | grep polkit
gdm       8130  0.0  0.2 242560  7680 ?        S    Aug02   0:00 /usr/libexec/polkit-gnome-authentication-agent-1
root      8139  0.0  0.1  49856  4252 ?        S    Aug02   0:00 /usr/libexec/polkit-1/polkitd
jbastian 13789  0.0  0.1 224204  5288 pts/0    S    10:34   0:00 /usr/libexec/polkit-gnome-authentication-agent-1
jbastian 16708  0.0  0.0 103152   832 pts/3    S+   11:04   0:00 grep polkit


$ /usr/libexec/polkit-gnome-authentication-agent-1

(polkit-gnome-authentication-agent-1:16752): GLib-GObject-WARNING **: cannot register existing type `_PolkitError'

(polkit-gnome-authentication-agent-1:16752): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

** (polkit-gnome-authentication-agent-1:16752): WARNING **: Unable to register authentication agent: Remote Exception invoking org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent() on /org/freedesktop/PolicyKit1/Authority at name org.freedesktop.PolicyKit1: org.freedesktop.PolicyKit1.Error.Failed: An authentication agent already exists for session
Cannot register authentication agent: Remote Exception invoking org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent() on /org/freedesktop/PolicyKit1/Authority at name org.freedesktop.PolicyKit1: org.freedesktop.PolicyKit1.Error.Failed: An authentication agent already exists for session

Comment 2 Daniel Berrangé 2010-08-18 16:15:39 UTC
> virt-manager should ask for a password if it fails to authenticate instead of
> giving a misleading error message.

This isn't possible with the architecture of policykit. virt-manager connects to the libvirtd daemon over a UNIX socket and libvirtd then askes policy kit to authenticate the connection. So virt-manager itself is never involved in authenticating, it is all out-of-band via PolicyKit. This sounds like its a problem with PolicyKit within VNC server sessions, possibly because VNC won't start/register any ConsoleKit session.

Comment 3 Jeff Bastian 2010-08-18 17:06:36 UTC
I'm a newbie with polkit so I don't know if I'm opening up security holes, but with a bit of experimentation I was able to create a pkla file that lets me start virt-manager in my VNC session without a password:

$ sudo cat /etc/polkit-1/localauthority/50-local.d/jbastian-libvirt.pkla
[jbastian libvirt Permissions]
Identity=unix-user:jbastian
Action=org.libvirt.*
ResultAny=yes
ResultInactive=yes
ResultActive=yes

Comment 4 Jeff Bastian 2010-08-18 17:14:35 UTC
Yeah, this is probably a more generic problem with PolicyKit and VNC rather than virt-manager.  I also noticed nm-applet was not running in my VNC session, so I tried starting it and got

$ nm-applet
** (nm-applet:21517): WARNING **: <WARN>  request_name(): Could not acquire the NetworkManagerUserSettings service.
  Error: (9) Connection ":1.495" is not allowed to own the service "org.freedesktop.NetworkManagerUserSettings" due to security policies in the configuration file

Comment 5 Jeff Bastian 2010-08-18 17:15:37 UTC
This is interesting: PackageKit also had this problem in VNC sessions and was just updated to allow it, see bug 528511.

Comment 6 Jeff Bastian 2010-08-18 21:04:00 UTC
I looked at the recent patch for PackageKit (see bug 528511) and tried making a similar change for libvirt.  I removed my custom /etc/polkit-1/localauthority/50-local.d/jbastian-libvirt.pkla file, then I made the following changes:

--- /usr/share/polkit-1/actions/org.libvirt.unix.policy.ORIG 2010-08-11 04:15:04.000000000 -0500
+++ /usr/share/polkit-1/actions/org.libvirt.unix.policy 2010-08-18 15:55:23.529641403 -0500
@@ -34,8 +34,8 @@
       <defaults>
         <!-- Only a program in the active host session can use libvirt in
              read-write mode for management, and we require user password -->
-        <allow_any>no</allow_any>
-        <allow_inactive>no</allow_inactive>
+        <allow_any>auth_admin</allow_any>
+        <allow_inactive>auth_admin</allow_inactive>
         <allow_active>auth_admin_keep</allow_active>
       </defaults>
     </action>


I restarted polkitd and my VNC session and when I tried to start virt-manager, it asked for the root password!  I entered the password and virt-manager started working.

Can we make the above change to the libvirt policy?

Comment 7 Jeff Bastian 2010-08-18 21:04:41 UTC
Changing componenet from virt-manager to libvirt.

Comment 8 Daniel Berrangé 2010-08-19 07:50:42 UTC
No, that change gives any local user full privileges to libvirtd. Since this is running as root and has the ability to change arbitrary host storage, networking, etc, you have effectively given all local users unauthenticated root access.

Comment 9 Daniel Berrangé 2010-08-19 07:56:11 UTC
Opps, no, i misread that. auth_admin is probably safe, provided you're using a secure remote channel (ie VNC + TLS/SSH).

Comment 10 Jeff Bastian 2010-08-19 14:01:15 UTC
Yes, I always tunnel through ssh.  Not only is it secure, I find it's easier than poking holes in the firewall to allow VNC traffic through.  (And 'vncviewer -via ...' makes the tunneling easier than 'ssh -L ...')

Comment 14 Daniel Berrangé 2011-02-10 12:21:59 UTC
system-config-keyboard is not an example of good design/practice. It is using the legacy consolehelper code which forces the entire application to run as root, which is deprecated because it is not a secure design pattern. The current recommended architecture is to run a daemon privileged, and the desktop application unprivileged & use policykit for authentication between the two. This is what virt-manager correctly does.

Comment 15 Dave Allan 2011-02-15 04:36:34 UTC
Assuming for a minute that the change proposed in comment 6 is correct, is that a libvirt change or a PolicyKit change?  I.e., should we change the component?

Comment 16 Jeff Bastian 2011-02-15 13:35:08 UTC
I think libvirt is the right component.

$ rpm -qf /usr/share/polkit-1/actions/org.libvirt.unix.policy
libvirt-0.8.1-27.el6.x86_64

Comment 17 Suzanne Logcher 2011-03-28 21:11:54 UTC
Since RHEL 6.1 External Beta has begun, and this bug remains 
unresolved, it has been rejected as it is not proposed as an 
exception or blocker.

Red Hat invites you to ask your support representative to 
propose this request, if appropriate and relevant, in the 
next release of Red Hat Enterprise Linux.

Comment 18 Levente Farkas 2011-04-20 13:04:20 UTC
the problem was something similar to this for us. one of our user delete the /usr/libexec/polkit-gnome-authentication-agent-1 from the strartup application (or copy from his home form an older rhel/fedora etc). and it was _very_ hard to find the reason. it'd be useful to popup an error message that the policykit agent is not running while it should have to be. and in this case even through vnc it is working _without_ the changes in #6.

Comment 21 Dave Allan 2012-01-09 21:41:05 UTC
Cole, what can we do here?  Is this really a libvirt problem or is it virt-manager?

Comment 22 Cole Robinson 2012-01-17 03:12:06 UTC
Dave, this isn't specific to virt-manager since it's we rely entirely on libvirt and policykit. Though I'm pretty sure this is expected behavior from policykit, it isn't intended to allow entering a root password over something like VNC or SSH -X AIUI.

Though it would be helpful if policykit, libvirt, or virt-manager could give a useful error about this limitation rather than the annoyingly opaque 'authentication failed'. But I'm not sure how to do that

Comment 23 Dave Allan 2012-01-17 04:05:16 UTC
(In reply to comment #22)
> Dave, this isn't specific to virt-manager since it's we rely entirely on
> libvirt and policykit. Though I'm pretty sure this is expected behavior from
> policykit, it isn't intended to allow entering a root password over something
> like VNC or SSH -X AIUI.

I just read over the transcript for bug 528511, and I agree with comment 6 and Dan's comment 9 that "auth_admin" is an acceptable fix, and it seems to have passed muster in bug 528511.  I've granted devel ack.

Comment 25 Cole Robinson 2012-02-07 17:58:25 UTC
Created attachment 560024 [details]
Allow polkit auth for SSH and VNC users

Also upstream:

http://libvirt.org/git/?p=libvirt.git;a=commit;h=756e6ab467a27e8228bfa2704d1c4883355ac666

Comment 28 Huang Wenlong 2012-02-14 08:50:27 UTC
Verify this bug with : 
libvirt-0.9.10-1.el6.x86_64



Steps to Reproduce:
1. as a regular user on a RHEL 6 system:
      vncserver -geometry 1024x768 -depth 24
2. from another system:
      vncviewer $rhel6-hostname:1
3. in the VNC session
      virt-manager   --debug

4. virt-manger  can start up , vurt-manager ask passwd for root ,after input passwd , it can works well

Comment 30 errata-xmlrpc 2012-06-20 06:24:39 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0748.html