On 02/14/2012 11:04 AM, Christophe Fergeau wrote:
It's possible to disable SPICE TLS in qemu.conf. When this
happens,
libvirt ignores any SPICE TLS port or x509 directory that may have
been set when it builds the qemu command line to use. However, it's
not ignoring the secure channels that may have been set and adds
tls-channel arguments to qemu command line.
Current qemu versions don't report an error when this happens, and try to use
TLS for the specified channels.
Before this patch
<domain type='kvm'>
<name>auto-tls-port</name>
<memory>65536</memory>
<os>
<type arch='x86_64' machine='pc'>hvm</type>
</os>
<devices>
<graphics type='spice' port='5900' tlsPort='-1'
autoport='yes' listen='0' ke
<listen type='address' address='0'/>
<channel name='main' mode='secure'/>
<channel name='inputs' mode='secure'/>
</graphics>
</devices>
</domain>
generates
-spice port=5900,addr=0,disable-ticketing,tls-channel=main,tls-channel=inputs
and after this patch we get
-spice port=5900,addr=0,disable-ticketing
Meta-question - if the XML requests secure, but TLS is disabled, should
we instead be failing to start the domain with a complaint that we can't
honor the XML?
If the answer is that we should start the domain anyways, and there is
just no security, because whoever disabled tls in qemu.conf knows what
they are doing, then ACK. If the answer is that we should error out on
an impossible configuration, then
+++ b/src/qemu/qemu_command.c
@@ -5286,8 +5286,9 @@ qemuBuildCommandLine(virConnectPtr conn,
int mode = def->graphics[0]->data.spice.channels[i];
switch (mode) {
case VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_MODE_SECURE:
- virBufferAsprintf(&opt, ",tls-channel=%s",
- virDomainGraphicsSpiceChannelNameTypeToString(i));
+ if (driver->spiceTLS)
+ virBufferAsprintf(&opt, ",tls-channel=%s",
+ virDomainGraphicsSpiceChannelNameTypeToString(i));
this needs an else clause that errors out.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org