RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1108523 - virt-viewer -c qemu+tcp will open local guest when remote VM is only listening on 127.0.0.1
Summary: virt-viewer -c qemu+tcp will open local guest when remote VM is only listenin...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-viewer
Version: 6.6
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Christophe Fergeau
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1179477
Blocks: 1108524
TreeView+ depends on / blocked
 
Reported: 2014-06-12 07:59 UTC by tingting zheng
Modified: 2015-07-22 06:31 UTC (History)
9 users (show)

Fixed In Version: virt-viewer-2.0-1.el6
Doc Type: Bug Fix
Doc Text:
**No doc needed** (keeping the text below in case we change our mind) Cause: When using a remote libvirt tcp connection, trying to connect to a VM listening on localhost would cause virt-viewer to try to connect to localhost. Fix: virt-viewer now checks if it's on a remote connection before trying to connect to a VM listening on 'localhost' Result: The scenario described above will report a connection failure.
Clone Of:
: 1108524 (view as bug list)
Environment:
Last Closed: 2015-07-22 06:31:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1322 0 normal SHIPPED_LIVE virt-viewer and spice-gtk bug fix and enhancement update 2015-07-20 17:53:14 UTC

Description tingting zheng 2014-06-12 07:59:59 UTC 
Description
virt-viewer -c qemu+tcp will open local guest when remote VM is only listening on 127.0.0.1

Version:
virt-viewer-0.6.0-5.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.On host A,set tcp server environment.
1.1 Edit /etc/sysconfig/libvirtd
       LIBVIRTD_ARGS="--listen"

1.2 Edit /etc/libvirt/libvirtd.conf
       listen_tls = 0
       listen_tcp=1
       auth_tcp="sasl"

1.3 Add a user named "fred", and setting his password as "redhat"
   # saslpasswd2 -a libvirt fred
   Password: xxxxxx
   Again (for verification): xxxxxx

1.4 Restart libvirtd service and set iptables.
# service libvirtd restart

#iptables -F

2.Prepare a spice guest rhel6.5 on host A,set it's listen address as 127.0.0.1,the xml shows as below:
# virsh dumpxml rhel6.5
    <graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>

3. On host B,prepare a spice guest winxp,set it's listen address as 127.0.0.1,the xml shows as below:
# virsh dumpxml winxp
    <graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>

4.On host B,use virt-viewer to launch remote guest rhel6.5 on host A,guest winxp on host B will be opened instead of rhel6.5 on host A.
# virt-viewer -c qemu+tcp://10.66.7.56/system rhel6.5

5.Repeat step 4 to connect remote vm through ssh,guest on host A can be opened successfully.
# virt-viewer -c qemu+ssh://10.66.7.56/system rhel6.5

Actual results：
As descripiton.

Expected results:
Guest booted on local host should not effect remote vm launched by virt-viewer.

Additional info:
1.If no guest booted on host B,step 4 will fail with error:Unable to connect to the graphic server 127.0.0.1:5900
2.The bug can be reproduced for vnc guest.
3.If guest on host A set listen address as '0.0.0.0',step 4 will connect to remote vm successfully.
Comment 2 Marc-Andre Lureau 2014-06-12 14:40:26 UTC 
Daniel, what's your take on this?

If the virConnectGetURI() has no transport, the extracted host is not localhost, and graphic host is localhost, then error out?
Comment 3 Daniel Berrangé 2014-06-12 14:47:03 UTC 
In this example, the URI *does* have a transport (+tcp) but we connect to the wrong one

> # virt-viewer -c qemu+tcp://10.66.7.56/system rhel6.5

It seems if <graphics> host is localhost, we can only connect if

  - URI transport is "" and URI hostname is ""
  - URI transport is "" and URI hostname is localhost/127.0.0.1/::1
  - URI transport is unix
  - URI transport is ssh
Comment 4 Christophe Fergeau 2014-06-12 15:39:51 UTC 
Can we get in a situation where the transport address is (eg) a public IP, and the <graphics> host is 10.0.x.y? This could also cause virt-viewer to try to connect to an unexpected VM if the client is not on the same local network as the destination VM.
Comment 5 Daniel Berrangé 2014-06-12 15:44:52 UTC 
(In reply to Christophe Fergeau from comment #4)
> Can we get in a situation where the transport address is (eg) a public IP,
> and the <graphics> host is 10.0.x.y? This could also cause virt-viewer to
> try to connect to an unexpected VM if the client is not on the same local
> network as the destination VM.

Yes, that's theoretically possible, but not sure there's any way in which we can detect that reliably. If they make their VM listen on an address that's not routable from the clients, we're basically doomed with all methods except SSH tunnelling.
Comment 6 Marc-Andre Lureau 2014-06-12 15:51:30 UTC 
Christophe, would you like to take care of this bug?
Comment 7 tingting zheng 2014-06-13 08:10:03 UTC 
The bug can also be reproduced when launching remote vm through tls connection.
Comment 8 Marc-Andre Lureau 2014-06-19 19:02:32 UTC 
posted:
https://www.redhat.com/archives/virt-tools-list/2014-June/msg00175.html
Comment 10 Jonathon Jongsma 2015-02-09 16:32:24 UTC 
will be soled by rebase to 2.0
Comment 12 zhoujunqin 2015-03-11 09:54:13 UTC 
I can reproduce this issue with package:
virt-viewer-0.6.0-5.el6.x86_64

Then try to verify with new build:
virt-viewer-2.0-2.el6.x86_64

steps:
1.On host A,set tcp server environment.
1.1 Edit /etc/sysconfig/libvirtd
       LIBVIRTD_ARGS="--listen"

1.2 Edit /etc/libvirt/libvirtd.conf
       listen_tls = 0
       listen_tcp=1
       auth_tcp="sasl"

1.3 Add a user named "fred", and setting his password as "redhat"
   # saslpasswd2 -a libvirt fred
   Password: xxxxxx
   Again (for verification): xxxxxx

1.4 Restart libvirtd service and set iptables.
# service libvirtd restart

#iptables -F

Scenario 1:
2.Prepare a spice guest rhel6u6-i386 on host A,set it's listen address as 127.0.0.1,the xml shows as below:
# virsh dumpxml rhel6u6-i386

    <graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>

3.1 On host B, there is no running guest, use virt-viewer to launch remote guest rhel6u6-i386 on host A
# virt-viewer -c qemu+tcp://10.66.7.91/system rhel6u6-i386

Result:after input user name and the sasl passwd cannot launch the guest with error: Guest 'rhel6u6-i386' is not reachable

3.2 On host B,prepare a spice guest win7-x64,set it's listen address as 127.0.0.1, use virt-viewer to launch remote guest rhel6u6-i386 on host A
# virsh dumpxml win7-x64
    <graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>

# virt-viewer -c qemu+tcp://10.66.7.91/system rhel6u6-i386

Result: When listen address is '127.0.0.1', cannot launch the guest with error:
Guest 'rhel6u6-i386' is not reachable

Scenario 2: Guest rhel6u6-i386 listen address is "0.0.0.0".
2.
# virsh dumpxml rhel6u6-i386
    <graphics type='spice' port='5900' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>

3.1 On host B, there is no running guest, use virt-viewer to launch remote guest rhel6u6-i386 on host A
# virt-viewer -c qemu+tcp://10.66.7.91/system rhel6u6-i386

3.2 On host B,prepare a spice guest win7-x64,set it's listen address as 0.0.0.0,use virt-viewer to launch remote guest rhel6u6-i386 on host A:

# virsh dumpxml win7-x64
    <graphics type='spice' port='5900' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>

# virt-viewer -c qemu+tcp://10.66.7.91/system rhel6u6-i386

Result: Guest rhel6u6-i386 can be launch successfully after input user name and the sasl passwd and both for there is a running guest on host B or not.

Scenario 3: Guest rhel6u6-i386 listen address is "0".
2. # virsh dumpxml rhel6u6-i386
    <graphics type='spice' port='5900' autoport='yes' listen='0'>
      <listen type='address' address='0'/>
    </graphics>

3.1. There is no running guest on host B, use virt-viewer to launch remote guest rhel6u6-i386 on host A

# virt-viewer -c qemu+tcp://10.66.7.91/system rhel6u6-i386

Result: After input user name and the sasl passwd , showed: Unable to connect to graphic server0:5900.

3.2 There is a running guest on host B listening '0', use virt-viewer to launch remote guest rhel6u6-i386 on host A
Result: After input user name and the sasl passwd, guest "win7-x64" on host B showed instead of guest "rhel6u6-i386" on host A.

So Christophe Fergeau, please help me have a look about verification steps, i think Scenario1 & Scenario2 are as expected, but i'm not sure about result for listenning on '0', is the result i got as expected or not,thanks.

And more info when i set rhel6u6-i386 listen address is '0', i can use following cmd launch guest on host A.

 # virt-viewer rhel6u6-i386
Comment 13 Christophe Fergeau 2015-03-17 11:12:55 UTC 
(In reply to zhoujunqin from comment #12)
> So Christophe Fergeau, please help me have a look about verification steps,
> i think Scenario1 & Scenario2 are as expected, but i'm not sure about result
> for listening on '0', is the result i got as expected or not,thanks.

As far as I can tell, the results you get for "0" is caused by a glib bug, I'll file a bug for that.
Comment 17 zhoujunqin 2015-03-18 08:53:16 UTC 
(In reply to Christophe Fergeau from comment #16)
> I believe the only case which is not working as expected is this "0" issue.
> If that is correct, then you can move this bug to VERIFIED.

Yes, that correct, thanks.
And according to Comment 12, move this bug to VERIFIED.
Comment 19 errata-xmlrpc 2015-07-22 06:31:08 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.

https://rhn.redhat.com/errata/RHBA-2015-1322.html
Note You need to log in before you can comment on or make changes to this bug.