Bug 879358

Summary: [RFE] Spice: overhaul spice secure/plain channel settings
Product: [oVirt] ovirt-engine Reporter: David Jaša <djasa>
Component: RFEsAssignee: Rob Young <royoung>
Status: CLOSED DEFERRED QA Contact: Shai Revivo <srevivo>
Severity: medium Docs Contact:
Priority: unspecified    
Version: ---CC: bugs, cfergeau, dblechte, desktop-qa-list, lpeer, mgoldboi, michal.skrivanek
Target Milestone: ---Keywords: FutureFeature, Improvement
Target Release: ---Flags: ylavi: ovirt-future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 803666, 874728    
Bug Blocks: 1039839    

Description David Jaša 2012-11-22 16:45:11 UTC
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:
http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vdsm/libvirtvm.py;h=3439dc374836de7509d9890bd6c5950c3b929938;hb=91090ebc87c603f0f2011e4dee58d3cb357b01e7#l831
to algorithm that browser plugins use (spice-x uses essentially the same):
http://cgit.freedesktop.org/spice/spice-xpi/tree/SpiceXPI/src/plugin/plugin.cpp?id=spice-xpi-2.8#n344
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


Conclusion
----------

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 14:51:13 UTC
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 09:47:17 UTC
*** Bug 874728 has been marked as a duplicate of this bug. ***

Comment 7 Michal Skrivanek 2018-04-16 07:52:50 UTC
*** Bug 1044457 has been marked as a duplicate of this bug. ***

Comment 8 Michal Skrivanek 2020-03-18 15:50:30 UTC
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 9 Michal Skrivanek 2020-03-18 15:54:58 UTC
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 10 Michal Skrivanek 2020-04-01 14:49:13 UTC
ok, closing. Please reopen if still relevant/you want to work on it.

Comment 11 Michal Skrivanek 2020-04-01 14:52:08 UTC
ok, closing. Please reopen if still relevant/you want to work on it.