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 805602 - validate numbers values, don't proceed if they are invalid
Summary: validate numbers values, don't proceed if they are invalid
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-xpi
Version: 6.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 6.4
Assignee: Peter Hatina
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-21 16:38 UTC by David Jaša
Modified: 2016-06-01 01:31 UTC (History)
9 users (show)

Fixed In Version: spice-xpi-2.7-22.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 10:57:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0459 0 normal SHIPPED_LIVE spice-xpi bug fix update 2013-02-20 21:07:29 UTC

Description David Jaša 2012-03-21 16:38:23 UTC
Description of problem:
if invalid port is specified, log error and don't proceed in the operation.

Version-Release number of selected component (if applicable):
spice-xpi-2.7-14.el6.x86_64

How reproducible:
always

Steps to Reproduce:
0. raise log level of spice-xpi
1. open test page
2. type some host to Host field
3. leave Port, SecurePort and UsbListenPort empty
4. hit "Connect"
  
Actual results:
  * "port" and "SecurePort" are not validated at all (spice-xpi tries to
    run client with string values of port)
  * if UsbListenPort is invalid, nothing is logged and value is set to 65535

Expected results:
  * validate all ports
  * spit error-level message if any of the values is invalid

Additional info:
  * empty string is valid value meaning that the variable should not be
    passed to the client at all
  * other values that are validate-able could possibly be validated as well,
    although most of them could live without it:
    * cipher suites
    * secure channels (their list should be autogenerated to prevent bugs
      caused by bit rotting)
    * hot keys
    * lanugage strings (if the regexp can be autogenerated)
    * USB filter (if the regexp can be autogenerated)
    * Trust store



example log of spice-xpi with port set to "a", SecurePort to "b" and UsbListenPort to "c" showing all the woes:

2012-03-21 17:24:45,988 DEBUG nsPluginInstance::SetHostIP: 127.0.0.1
2012-03-21 17:24:45,988 DEBUG nsPluginInstance::SetPort: a
2012-03-21 17:24:45,989 DEBUG nsPluginInstance::SetSecurePort: b
2012-03-21 17:24:45,989 DEBUG nsPluginInstance::SetPassword: Password set
2012-03-21 17:24:45,989 DEBUG nsPluginInstance::SetCipherSuite: 
2012-03-21 17:24:45,989 DEBUG nsPluginInstance::SetSSLChannels: 
2012-03-21 17:24:45,990 DEBUG nsPluginInstance::SetTrustStore: 
2012-03-21 17:24:45,990 DEBUG nsPluginInstance::SetHostSubject: 
2012-03-21 17:24:45,990 DEBUG nsPluginInstance::SetFullScreen: 0
2012-03-21 17:24:45,991 DEBUG nsPluginInstance::SetAdminConsole: 0
2012-03-21 17:24:45,991 DEBUG nsPluginInstance::SetTitle: 
2012-03-21 17:24:45,991 DEBUG nsPluginInstance::SetDynamicMenu: 
2012-03-21 17:24:45,991 DEBUG nsPluginInstance::SetNumberOfMonitors: 
2012-03-21 17:24:45,992 DEBUG nsPluginInstance::SetGuestHostName: 
2012-03-21 17:24:45,992 DEBUG nsPluginInstance::SetHotKeys: toggle-fullscreen=shift+f11,release-cursor=shift+f12,smartcard-insert=shift+f8,smartcard-remove=shift+f9
2012-03-21 17:24:45,992 DEBUG nsPluginInstance::SetNoTaskMgrExecution: 0
2012-03-21 17:24:45,992 DEBUG nsPluginInstance::SetSendCtrlAltDelete: 0
2012-03-21 17:24:45,993 DEBUG nsPluginInstance::SetUsbListenPort: 65535
2012-03-21 17:24:45,993 DEBUG nsPluginInstance::SetUsbAutoShare: 0
2012-03-21 17:24:45,993 DEBUG nsPluginInstance::GetHostIP: 127.0.0.1
2012-03-21 17:24:45,994 DEBUG nsPluginInstance::GetHostIP: 127.0.0.1
2012-03-21 17:24:45,994 DEBUG nsPluginInstance::GetPort: a
2012-03-21 17:24:45,994 DEBUG nsPluginInstance::GetPort: a
2012-03-21 17:24:45,994 DEBUG nsPluginInstance::GetSecurePort: b
2012-03-21 17:24:45,994 DEBUG nsPluginInstance::GetSecurePort: b
2012-03-21 17:24:45,994 DEBUG nsPluginInstance::GetUsbListenPort: 65535
2012-03-21 17:24:45,995 INFO  nsPluginInstance::Connect: SPICE_XPI_SOCKET: /tmp/spicec-P1lwnq/spice-xpi
2012-03-21 17:24:45,995 INFO  nsPluginInstance::Connect: SPICE_FOREIGN_MENU_SOCKET: /tmp/spicec-P1lwnq/spice-foreign
2012-03-21 17:24:45,996 DEBUG nsPluginInstance::Connect: Controller pid: 9685
2012-03-21 17:24:45,996 DEBUG QErrorHandler: Something went wrong: connect error, 2
2012-03-21 17:24:45,996 DEBUG SpiceController::Connect: Connect Error
2012-03-21 17:24:45,996 DEBUG QErrorHandler: Something went wrong: connect error, 2
2012-03-21 17:24:45,996 INFO  nsPluginInstance::Connect: Launching /usr/libexec/spice-xpi-client 
2012-03-21 17:24:45,996 DEBUG SpiceController::Connect: Connect Error
2012-03-21 17:24:46,997 DEBUG QErrorHandler: Something went wrong: connect error, 2
2012-03-21 17:24:46,997 DEBUG SpiceController::Connect: Connect Error
2012-03-21 17:24:48,997 DEBUG SpiceController::Connect: Connected!
2012-03-21 17:24:52,012 INFO  nsPluginInstance::Connect: Initiating connection with controller
2012-03-21 17:24:52,034 DEBUG nsPluginInstance::ExecuteUsbRdrCtrl: Connection name: /tmp/spicec-P1lwnq/spice-foreign
2012-03-21 17:24:54,034 INFO  nsPluginInstance::ExecuteUsbRdrCtrl: Launching /usr/bin/usbrdrctrl  65535 -c /tmp/spicec-P1lwnq/spice-foreign      
2012-03-21 17:33:01,764 DEBUG nsPluginInstance::ControllerWaitHelper: Controller finished, pid: 9685, exit code: 0
2012-03-21 17:33:01,764 ERROR nsPluginInstance::CallOnDisconnected: could not get browser window, when trying to call OnDisconnected
2012-03-21 17:33:02,234 DEBUG nsPluginInstance::UsbRdrCtrlWaitHelper: usbrdrctrl finished, pid: 9694, exit code: 0

Comment 1 Marc-Andre Lureau 2012-03-21 16:50:01 UTC
It's not spice-xpi job to validate arguments, since the various programs spawned are the one consuming them, and spice-xpi is not responsible for coming up with those values. But it could help to identify more easily the guilty part if it would do some sanity check at spice-xpi level. Though, I would lower priority/severity of this bug.

Comment 2 Alon Levy 2012-03-21 17:21:43 UTC
It seems to happen for vanilla ovirt installs. I'm not sure the priority/severity should be lowered.

Comment 3 Marc-Andre Lureau 2012-03-21 17:28:38 UTC
(In reply to comment #2)
> It seems to happen for vanilla ovirt installs. I'm not sure the
> priority/severity should be lowered.

But spice-xpi is not responsible, it would be more appropriate in the html page or at the ovirt server level, or both. spice-xpi isn't going to tell us where the problem come from.

Comment 4 Peter Hatina 2012-04-03 08:14:31 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > It seems to happen for vanilla ovirt installs. I'm not sure the
> > priority/severity should be lowered.
> 
> But spice-xpi is not responsible, it would be more appropriate in the html page
> or at the ovirt server level, or both. spice-xpi isn't going to tell us where
> the problem come from.

As Marc-Andre said - spice-xpi is kind of proxy between the web page and the spicec/remote-viewer. On the other hand, it would make sense, if spice-xpi does not blindly execute a process with nonsense parameters.

Comment 6 Peter Hatina 2012-04-25 13:19:53 UTC
Einav, can you, please, clarify whether RHEV-M is able to send via spice-xpi one of 2 ports (secured or unsecured one)? If one of those ports is not used, what values are sent? Something specifc, eg. -1 or empty string?

Comment 7 Einav Cohen 2012-04-25 19:00:28 UTC
(In reply to comment #6)
> Einav, can you, please, clarify whether RHEV-M is able to send via spice-xpi
> one of 2 ports (secured or unsecured one)? If one of those ports is not used,
> what values are sent? Something specifc, eg. -1 or empty string?

RHEV-M sends to spice-xpi the "displaySecurePort" and "displayPort" values as reported by vdsm for the relevant VM via the 'getVmStats' vdsm verb.

In case one of these values, for some reason, isn't reported from vdsm, RHEV-M will set "0" in the relevant spice-xpi property; i.e. if "displaySecurePort" isn't reported from vdsm, RHEV-M will set "0" in the spice-xpi "SecurePort" property; if "displayPort" isn't reported from vdsm, RHEV-M will set "0" in the spice-xpi "port" property.

I am not sure if/when/how frequently "displaySecurePort" and/or "displayPort" aren't reported from vdsm. Please consult someone from the vdsm team if you need this information.

Comment 8 Einav Cohen 2012-04-26 07:06:46 UTC
Some clarification after discussions in rhev-devel:
[http://post-office.corp.redhat.com/mailman/private/rhev-devel/2012-April/msg00281.html]

- There are scenarios in which RHEV-M sends to spice-xpi SecurePort = "-1" (for spice with insecure communication).

- There are scenarios in which RHEV-M sends to spice-xpi port = "-1" and SecurePort = "-1" (when VM is in "Powering Up" status / for the VM's initial boot period, until qemo starts listening to the spice ports).

- There might be corner cases in which RHEV-M will send to spice-xpi port = "0" and SecurePort = "0" (highly improbable IMO).

Comment 9 Peter Hatina 2012-04-26 08:15:50 UTC
Einav, you said, that there is a scenario, when one of the ports can be "0". Does it make sense to start spicec/remote-viewer, with ports 0? Port 0 is the
first valid and reserved transport layer port, but what does it indicate? The
port is unused or can be used? What I am trying to figure out, when to start
controller and when to log an error and do nothing. The value "-1" is clear,
that port is unused, but can you explain, what does "0" indicate? Should I just
run controller?

Comment 11 David Blechter 2012-05-15 14:05:16 UTC
agreed, moving to 6.4

Comment 13 Einav Cohen 2012-07-11 07:59:11 UTC
(In reply to comment #9)
> Einav, you said, that there is a scenario, when one of the ports can be "0".
> Does it make sense to start spicec/remote-viewer, with ports 0? Port 0 is the
> first valid and reserved transport layer port, but what does it indicate? The
> port is unused or can be used? What I am trying to figure out, when to start
> controller and when to log an error and do nothing. The value "-1" is clear,
> that port is unused, but can you explain, what does "0" indicate? Should I
> just
> run controller?

AFAIK, "0" and "-1" mean the same thing in our (rhevm GUI) point of view, i.e., port is unused. And again, sending "0" is highly improbable.

Comment 15 Peter Hatina 2012-08-01 08:50:29 UTC
Fixed.

Comment 19 errata-xmlrpc 2013-02-21 10:57:50 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/RHBA-2013-0459.html


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