| Summary: | using polkit with virsh for non-root access does not work via ssh on a remote host | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Fangge Jin <fjin> |
| Component: | libvirt | Assignee: | John Ferlan <jferlan> |
| Status: | CLOSED ERRATA | QA Contact: | yafu <yafu> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.3 | CC: | dyuan, jferlan, lhuang, mzhan, rbalakri, xuzhang, yafu |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-3.2.0-7.el7 | Doc Type: | No Doc Update |
| Doc Text: |
undefined
|
Story Points: | --- |
| Clone Of: | 986365 | Environment: | |
| Last Closed: | 2017-08-01 17:14:13 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Fangge Jin
2016-09-08 03:09:11 UTC
I posted a couple of patches: https://www.redhat.com/archives/libvir-list/2017-May/msg00320.html Either of which will avoid the infinite authentication loop. The details are in the referenced cover letter posting. Either of the patches would work, the first would just cause an 'extra' authn challenge/response for something like ssh; whereas, the second one would fail after the first challenge/response failure. Note that this "failure scenario" only occurs because the username is not root (or whatever name would result in a UID==0). I almost went down the path of well maybe we should allow this non-root path to check if the authn callerUid was in the right group to allow the access; however, that type of processing appears to be "outside" the scope of the problem description. The following patch has been pushed upstream:
commit 2453501fc82d3b247affb6c9054dc65bf2f669b3
Author: John Ferlan <jferlan>
Date: Thu May 11 09:17:09 2017 -0400
virsh: Track when create pkttyagent
...
Due to how the processing for authentication using polkit works, the
virshConnect code must first "attempt" an virConnectOpenAuth and then
check for a "special" return error code VIR_ERR_AUTH_UNAVAILABLE in
order to attempt to "retry" the authentication after performing a creation
of a pkttyagent to handle the challenge/response for the client.
However, if pkttyagent creation is not possible for the authentication
being attempted (such as perhaps a "qemu+ssh://someuser@localhost/system"),
then the same failure pattern would be returned and another attempt to
create a pkttyagent would be done. This would continue "forever" until
someone forced quit (e.g. ctrl-c) from virsh as the 'authfail' was not
incremented when creating the pkttyagent.
So add a 'agentCreated' boolean to track if we've attempted to create the
agent at least once and force a failure if that creation returned the same
error pattern.
This resolves a possible never ending loop and will generate an error:
error: failed to connect to the hypervisor
error: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage'
NB: If the authentication was for a sufficiently privileged client, such as
qemu+ssh://root@localhost/system, then the remoteDispatchAuthList "allows"
the authentication to use libvirt since @callerUid would be 0.
$
$ git describe 2453501fc82d3b247affb6c9054dc65bf2f669b3
v3.3.0-137-g2453501
$
It will have the failure scenario from the description where 2 attempts are made to authenticate, although the second will fail as follows:
$ virsh -c qemu+ssh://localhost/system list --all
someuser@localhost's password:
someuser@localhost's password:
error: failed to connect to the hypervisor
error: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage'
$
or
$ virsh -c qemu+ssh://someuser@localhost/system list --all
someuser@localhost's password:
someuser@localhost's password:
error: failed to connect to the hypervisor
error: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage'
$
The root access would still be allowed:
$ virsh -c qemu+ssh://root@localhost/system list --all
root@localhost's password:
Id Name State
----------------------------------------------------
- domain shut off
...
Reproduced with libvirt-2.0.0-1.el7.x86_64. Verified pass with libvirt-3.2.0-9.virtcov.el7.x86_64. Test steps: 1.Connect without setting user: $ virsh -c qemu+ssh://localhost/system list yafu@localhost's password: yafu@localhost's password: error: failed to connect to the hypervisor error: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage' 2.Connect with another non-root user: $virsh -c qemu+ssh://test@localhost/system list test@localhost's password: test@localhost's password: error: failed to connect to the hypervisor error: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage' 3.Connect with a non-exist user: $ virsh -c qemu+ssh://test-none@localhost/system list test-none@localhost's password: test-none@localhost's password: test-none@localhost's password: error: failed to connect to the hypervisor error: Cannot recv data: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer 4.Connect with root: $virsh -c qemu+ssh://root@localhost/system --list root@localhost's password: Id Name State ---------------------------------------------------- - full-73 shut off 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. https://access.redhat.com/errata/RHEA-2017:1846 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. https://access.redhat.com/errata/RHEA-2017:1846 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. https://access.redhat.com/errata/RHEA-2017:1846 |