Bug 879358 - [RFE] Spice: overhaul spice secure/plain channel settings
[RFE] Spice: overhaul spice secure/plain channel settings
Status: NEW
Product: ovirt-engine
Classification: oVirt
Component: RFEs (Show other bugs)
Unspecified Unspecified
unspecified Severity medium (vote)
: ---
: ---
Assigned To: Rob Young
Shai Revivo
: FutureFeature, Improvement
: 874728 (view as bug list)
Depends On: 803666 874728
  Show dependency treegraph
Reported: 2012-11-22 11:45 EST by David Jaša
Modified: 2017-11-16 07:51 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?

Attachments (Terms of Use)

  None (edit)
Description David Jaša 2012-11-22 11:45:11 EST
Description of problem

There are several shortcomings when it comes to setting of the secure channels:

1) channel names are still prepended with "s" which is obsolete since 3.0 clusters (bug 803666) so there is no reason to keep this anachronism and associated workarounds in vdsm and browser plugins from 3.2 on

2) configuration model is tailored to the model of "plaintext by default, whitelist SSL ones" while currently desired behaviour is "tls by default", possibly with whitelist of plaintext channel

3) if tls (or plaintext for that matter) channels are to be used exclusively, there's no need to waste listening port on the host for the other variant (and cpu cycles and network frames to communicate the other settings): bug 874728

High-level proposal of implementation

1. from 3.2 on, drop "s" from the channel names in RHEV-M configuration

2. modify configuration database logic:
  * add "SpicePlaintextChannels" configuration option (or
        similarly named
  * add "default" and when RFE bug 874728 is implemented (RHEL 6.5
        time frame), also special "all" channels
  * make these values interdependent in this way:
    * "all" and "default" can only be set on one of
          Spice*Channels options
    * option can be set to "all" only if the other option is empty
    * one option set to "default" exlcudes any other channel to
          be set in that option, individual channels can be set
          in the other option
  * default configuration should be either SpiceSecureChannels=default
        or all and SpicePlaintextChannel empty
I hope that the points above are clear but if they aren't, I can add examples to the comment.

3. solve compatibility with 3.0 and 3.1 hosts either by changing "m.setAttribute('name', channel[1:])" in this loop:
to algorithm that browser plugins use (spice-x uses essentially the same):
This approach doesn't need any engine modification but it needs modifications in 3.1.z vdsm (and 3.0.z if it will be manageable by 3.2 engine), but these transition period workarounds can be limited to just .z releases and they don't have to haunt future developers in master

The alternative is to add converse loop to the one in vdsm to the engine that will prepend "s" to channel names for 3.1 and older hosts - with some comment to remove it again when 3.1 and older hosts will EOL.

4. browser plugins are ready for secure channel names without "s" prefix and to send "default" value to the client (so that client connects to the correct port right away but clients ignore it yet: bug 879346 and bug 879352), but they are not yet ready to send list of plaintext channels: RFE bug 879343. This shouldn't be of much issue however if they can handle setting of the unimplemented plugin property.

5. Spice*Channels=all (bug 874728) can be implemented after the reset of this proposal, when libvirt bug 875730 get implemented


In my not so humble opinion, this feature, despite broad in scope, doesn't require much of actual developer/qa time to be implemented so it should be implemented rather soon than later.
Comment 1 David Jaša 2013-07-12 10:51:13 EDT
Note how libvirt implements the default channel security setting:

The defaultMode attribute sets the default channel security policy, valid values are secure, insecure and the default any (which is secure if possible, but falls back to insecure rather than erroring out if no secure path is available). "defaultMode" since 0.9.12.

actual configuration schema in RHEV could mirror libvirts schema of defaultMode + <channel name="actual_channel" mode="mode"/> rather than use spice-server configuration schema with meta-channel "default".
Comment 2 Michal Skrivanek 2013-08-05 05:47:17 EDT
*** Bug 874728 has been marked as a duplicate of this bug. ***

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