Bug 872166 - RFE: virsh should provide a simple polkit text agent, so polkit password prompt works over ssh -X
RFE: virsh should provide a simple polkit text agent, so polkit password prom...
Status: CLOSED UPSTREAM
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: John Ferlan
:
: 984289 (view as bug list)
Depends On:
Blocks: 986365
  Show dependency treegraph
 
Reported: 2012-11-01 08:41 EDT by Richard W.M. Jones
Modified: 2016-05-09 10:28 EDT (History)
29 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 986365 (view as bug list)
Environment:
Last Closed: 2016-03-01 10:05:33 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2012-11-01 08:41:44 EDT
Description of problem:

$ virsh --connect qemu:///system list
error: authentication failed: polkit\56retains_authorization_after_challenge=1
Authorization requires authentication but no agent is available.

error: failed to connect to the hypervisor

What's particularly annoying about this error is that it
is not actionable.  It doesn't say what "agent" needs to be
running or what other steps the user can take to fix the
error.

libvirt-0.10.2-3.fc18.x86_64
polkit-0.107-3.fc18.x86_64

SELinux is permissive.

'/usr/sbin/libvirtd' is running.
'/usr/lib/polkit-1/polkitd --no-debug' is running.
Comment 1 Cole Robinson 2012-12-16 18:36:42 EST
This error is coming from polkit as explained here:

https://www.redhat.com/archives/libvir-list/2012-December/msg00976.html

If your login session didn't autolaunch a polkit agent (which happens over ssh -X), I think the only option here is for virsh to register its own agent to make this work in all cases.

pkcheck has a --use-internal-agent option which launches a text user/password prompt, but that doesn't help us since it's being run by the daemon, not the client process.
Comment 2 Cole Robinson 2013-07-15 16:03:58 EDT
*** Bug 984289 has been marked as a duplicate of this bug. ***
Comment 3 David Gibson 2013-07-15 20:16:06 EDT
I think this is more serious than a mere RFE.

This makes virsh totally unusable from a text console in the default configuration.
Comment 4 Laine Stump 2013-07-15 22:01:20 EDT
How about "sudo virsh ..." ? I think most people do that (or, like me, just run it from a root shell).
Comment 5 David Gibson 2013-07-15 22:44:27 EDT
Hm.  I could have sworn I tried sudo virsh and still couldn't get it to work.  But I can't seem to reproduce the problem now.
Comment 6 Kashyap Chamarthy 2014-02-07 01:34:05 EST
(In reply to David Gibson from comment #3)
> I think this is more serious than a mere RFE.
> 
> This makes virsh totally unusable from a text console in the default
> configuration.

I agree with David here. I just got a couple of reports (from seasoned Linux admins) asking what to do about these kind of issues (to run virsh to connect to remote machines as an unprivileged user). If it's this much of a hassle for regular admins, I can imagine an unsuspecting, casual linux administrator going "ugh"
Comment 7 Yanis Guenane 2014-03-30 12:21:21 EDT
To add an extra case on where running `sudo virsh ...` is not always possible is when a user is running vagrant for example. Vagrant does provide a libvirt backend driver, and vagrant is used to run as a non-privileged user.

On a CI infrastructure we can imagine Jenkins running test on a vagrant-libvirt machine, but since the host wouldn't have any X it will result in the same error initially mentionned.
Comment 8 Cole Robinson 2014-03-30 13:42:38 EDT
(In reply to Yanis Guenane from comment #7)
> To add an extra case on where running `sudo virsh ...` is not always
> possible is when a user is running vagrant for example. Vagrant does provide
> a libvirt backend driver, and vagrant is used to run as a non-privileged
> user.
> 
> On a CI infrastructure we can imagine Jenkins running test on a
> vagrant-libvirt machine, but since the host wouldn't have any X it will
> result in the same error initially mentionned.

This bug is only about an interactive password polkit password prompt, which wouldn't really make sense in a test suite. To do something like what you propose you should probably use a polkit override, so the unprivileged vagrant user can access the system libvirt instance without auth.
Comment 9 Pete Travis 2015-03-05 18:27:33 EST
What about shipping something like this below at least in %doc, with comments about dropping it in /etc/polkit-1/rules.d/ ? It would allow trusted non-root users to do `--connect qemu+ssh`, covering Kashyap's cited use case.

```
polkit.addRule(function(action, subject) {
        polkit.log("action=" + action);
        polkit.log("subject=" + subject);
        var now = new Date();
        polkit.log("now=" + now)
        if ((action.id == "org.libvirt.unix.manage" || action.id == "org.libvirt.unix.monitor") && subject.isInGroup("virt-adm")) {
        return polkit.Result.YES;
        }
        return null;
        });
```
Comment 10 John Ferlan 2015-07-27 09:35:53 EDT
It seems what is desired for this bug is fixed with the changes Cole made for bug 957300.  Before I dupe it to that - I wanted to make sure you agree.
Comment 11 Richard W.M. Jones 2015-08-04 07:31:57 EDT
Not sure I can say if the fix for the other bug is the right one.

My main concern when filing the bug was that the error message
was not actionable (note the Summary of this bug has changed since
I filed it).
Comment 12 John Ferlan 2016-02-12 13:26:19 EST
I've posted some patches upstream which will address the concerns

(now at v3): 

  http://www.redhat.com/archives/libvir-list/2016-February/msg00657.html


Patch 1 of the series adjusts the error message to be a bit more clear about which "agent" is causing the issue

Patches 2 & 3 add support for a text based authentication agent.
Comment 13 John Ferlan 2016-03-01 06:58:50 EST
Patches w/ some slight adjustments (all listed within the reviews of the above link) have been pushed upstream. This will appear in what should be libvirt 1.3.3 (the March 2016 release).

v1.3.2-21-gea48397

commit ea48397b016683933104c5ce059a33443a79cdbb
Author: John Ferlan <jferlan@redhat.com>
Date:   Tue Feb 9 14:08:42 2016 -0500

    virsh: Add support for text based polkit authentication
Comment 14 Cole Robinson 2016-03-01 10:05:33 EST
Thanks John, though I think it's fine to just close as UPSTREAM once it's committed
Comment 15 yafu 2016-03-15 22:58:39 EDT
Hi, John, I tested the patch with libvirt-1.3.3-1.fc24_v1.3.2_167_g885e34c.x86_64 , and only the error message becomes more clear. It is expected to show password prompt? Could you help me to check is there anything wrong with my test steps? Thanks a lot.

My test steps are as follows:
1.Add a non-root user and set password for the user:
 #useradd test
 #passwd test 

2.Login with test user using "ssh -X":
 #ssh -X test@127.0.0.1

3.Run "virsh -c qemu:///system" with test user:
 $virsh -c qemu:///system
2016-03-15 05:30:09.852+0000: 6141: info : libvirt version: 1.3.3, package: 1.fc24_v1.3.2_167_g885e34c (Unknown, 2016-03-15-07:03:36, localhost.localdomain)
2016-03-15 05:30:09.852+0000: 6141: info : hostname: localhost.localdomain
2016-03-15 05:30:09.852+0000: 6141: warning : virFileClose:96 : Tried to close invalid fd 7
error: failed to connect to the hypervisor
error: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage'

4.Login using "ssh test@127.0.0.1" also got the same error message.
Comment 16 John Ferlan 2016-03-16 06:38:51 EDT
My testing usually occurs on my laptop where I initially login under my account.

Running virsh -c qemu:///system list --all there causes the GUI version of the polkit tools to kick in; however, if I simply ssh jferlan@localhost then run the same command I see the following:

$ virsh -c qemu:///system version
==== AUTHENTICATING FOR org.libvirt.unix.manage ===
System policy prevents management of local virtualized systems
Authenticating as: John Ferlan (jferlan)
Password: 
==== AUTHENTICATION COMPLETE ===
Compiled against library: libvirt 1.3.3
Using library: libvirt 1.3.3
Using API: QEMU 1.3.3
Running hypervisor: QEMU 2.4.1


I have no difference if I use ssh -X using this mechanism.

I can also login under my account, su to root, and ssh to my local account and get the same results.
Comment 17 Luyao Huang 2016-05-09 03:09:55 EDT
Another QE and I also met the same problem mentioned in comment 15 on v1.3.4-169-g1617134

and i find the problem seems come from commit 0b36b0e9, and the problem is:

    agent->cmd = cmd;                    <-
    cmd = NULL;                          <--- give cmd ptr to agent->cmd here

    virCommandAddArgFormat(cmd, "%lld", (long long int) getpid());  <----but still use cmd ptr here which is NULL now.

    ... 
    if (virCommandRunAsync(cmd, NULL) < 0)  <----- still use cmd, get failure
        goto error;

And i had a try to fix it and found it works after apply my patch:

$ ssh lhaung@localhost -X
lhaung@localhost's password: 
Last login: Mon May  9 14:25:48 2016 from localhost
[lhaung@lhuang ~]$ virsh -c qemu:///system
==== AUTHENTICATING FOR org.libvirt.unix.manage ===
System policy prevents management of local virtualized systems
Authenticating as: root
Password: 
==== AUTHENTICATION COMPLETE ===
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh #
Comment 18 Richard W.M. Jones 2016-05-09 04:03:55 EDT
Commit 0b36b0e9 does look wrong.  Perhaps the subsequent lines
should be using agent->cmd instead?
Comment 19 Peter Krempa 2016-05-09 04:39:47 EDT
Yes, that commit is totally wrong. In addition virPolkitAgentDestroy already clears the passed virCommand pointer so a simple rearrange of the code would have helped at that point. I'll post a patch to fix that.
Comment 20 Peter Krempa 2016-05-09 10:28:16 EDT
commit 4e8b81e5c4bbc5b26032e61a8006cda0b393ef8b
Author: Peter Krempa <pkrempa@redhat.com>
Date:   Mon May 9 11:02:51 2016 +0200

    util: polkit: Fix polkit agent startup
    
    Commit 0b36b0e9 broke polkit agent startup when attempting to fix a
    coverity warning. Refactor it properly so that we don't need the 'cmd'
    intermediate variable.

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