Bug 635529

Summary: libvirt clients without PolicyKit compiled in, can't authenticate to libvirt servers over SSH using it
Product: [Community] Virtualization Tools Reporter: Justin Clift <jclift>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: high Docs Contact:
Priority: low    
Version: unspecifiedCC: crobinso, derek, kwade, xen-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-26 15:47:30 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
The libvirt daemon log extract from the failure. Only 137 lines. none

Description Justin Clift 2010-09-20 05:03:46 UTC 
Description of problem:

A libvirt client (ie virsh) built without support for PolicyKit isn't able to connect to a libvirt daemon that *is* using PolicyKit, over SSH.

(The same client can authenticate using TLS though.)

For example, if a client is built using "--without-polkit" on Linux, or is built on an OS with PolicyKit (Mac OS X), connecting over SSH will give:

  $ virsh -d 5 -c 'qemu+ssh://username@hostname/system'
  error: authentication failed: unsupported authentication type 2
  error: failed to connect to the hypervisor
  $

This failure message is returned _after_ the SSH layer has been successfully established, when netcat connects to the socket file.

The libvirt daemon receives the connection, but immediately drops it. (unsure why at this stage)

*THIS IS THE BUG*

Even though PolicyKit wasn't compiled into the libvirt client, PolicyKit on the server is what's responsible for the auth checking, and it successfully does this.  The libvirt daemon shouldn't then drop the connection after the client has auth'd ok.


Version-Release number of selected component (if applicable):

Present git head of libvirt.  0.8.4+


How reproducible:

Every time.


Steps to Reproduce:
1. Build virsh using "--without-polkit" on the ./configure line
2. Use it to connect to a RHEL6 or Fedora 13 box that has PolicyKit enabled (it is by default)
3. Even if the user has sufficient authorisation, the libvirt daemon drops the connection.  This is the bug.

  
Actual results:

  The libvirt daemon drops the connection.


Expected results:

  The libvirt client should be able to use the established connection.  It has, after all, already authenticated ok.


Additional info:

  Possibly the only workaround for Mac OS X clients for now, until this is fixed, is to disable PolicyKit usage by libvirt on the server side.  Open to other suggestions. :)
Comment 1 Justin Clift 2010-09-20 05:05:18 UTC 
Created attachment 448351 [details]
The libvirt daemon log extract from the failure.  Only 137 lines.
Comment 2 Justin Clift 2010-09-20 05:07:04 UTC 
Typo in the above text.  It should say:

  "... or is built on an OS **WITHOUT** PolicyKit (Mac OS X), ..."
Comment 3 Derek Ditch 2015-06-29 15:04:10 UTC 
There hasn't been any activity on this for over 3 years, yet this is still a problem. I was attempting to use Vagrant from my Mac to a RHEL7.1 Workstation using libvirt, but it appears that I cannot, because of this bug.

Is there any hope? Is there a work around? Can we at least update the documentation so users like me don't fight this for a couple hours?
Comment 5 Cole Robinson 2016-04-14 19:42:24 UTC 
Sorry this never received a timely response. I've sent a patch upstream now:

http://www.redhat.com/archives/libvir-list/2016-April/msg00932.html
Comment 6 Cole Robinson 2016-04-26 15:47:30 UTC 
Upstream now:

commit 84371303d8302e59e535b4ca2d7e2d5f43d7679e
Author: Cole Robinson <crobinso>
Date:   Thu Apr 14 14:58:40 2016 -0400

    remote: Don't reject remote polkit if client lacks support