On 06/05/2013 07:11 AM, Daniel P. Berrange wrote:
On Wed, Jun 05, 2013 at 03:09:54PM +0200, Ján Tomko wrote:
> QEMU does accept empty VNC passwords now and allows anyone
> to connect with an empty password.
>
>
https://bugzilla.redhat.com/show_bug.cgi?id=969542
> ---
> src/qemu/qemu.conf | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
> index cdf1ec4..49ef75f 100644
> --- a/src/qemu/qemu.conf
> +++ b/src/qemu/qemu.conf
> @@ -62,9 +62,9 @@
> # VNC passwords. This parameter is only used if the per-domain
> # XML config does not already provide a password. To allow
> # access without passwords, leave this commented out. An empty
> -# string will still enable passwords, but be rejected by QEMU,
> -# effectively preventing any use of VNC. Obviously change this
> -# example here before you set this.
> +# string might either prevent any use of VNC or allow access
> +# with an empty password depending on QEMU version. Obviously
> +# change this example here before you set this.
> #
> #vnc_password = "XYZ12345"
NACK. This is not correct. This is a security flaw and regression
in behaviour that must be fixed, if true.
Agreed - even if qemu has changed behavior on what the empty string
means, WE have documented it to mean no access permitted, and we MUST
stick with our definition (even if it means probing qemu's functionality
and behaving differently according to what qemu we are controlling). We
already document that there is a difference between omitting the
vnc_password line item (allowing access) and supplying an empty string
(denying access).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org