On 5 January 2015 at 18:13, Daniel P. Berrange <berra...@redhat.com> wrote: > Configuring 0.0.0.0 and no auth is a valid setup *provided* the virtualization > host itself is on a secured network. In fact this is the normal setup for an > OpenStack deployment, since the virt host/VNC server is not intended to ever > be directly exposed to the internet. Instead the user accesses the VNC server > via an authenticated VNC proxy tunnelled over HTTPs. So printing out such an > error message or refusing to launch would be wrong - QEMU doesn't know the > context of how it is being used.
Well, the question is what the default should be, and whether you should have to take explicit action to enable a possibly-insecure configuration. At the moment you don't, and this seems to have resulted in a lot of people presumably unintentionally leaving themselves wide open to access from the internet. So it comes down to "are we willing to one-time break currently working configs for people with openstack type deployments who will now need to put no-auth-is-ok in their command line switches, in order to protect new users against shooting themselves in the foot without realising it?". You could argue it either way... >> Seems reasonable to me. Some questions: >> * do we need an option for "yes, I know what I'm doing and do not >> want any authentication" ? >> * how many of these VMs are configured for wide-open VNC by libvirt or >> similar management tool rather than by the user directly running QEMU? > > Libvirt will always set the listen address to 127.0.0.1 if not otherwise > specified, and so not rely on QEMU's (insecure) default. So if any VMs > managed by libvirt are using a public IP address, this was requested > explicitly by the admin or the mgmt app using libvrt. That's good to hear. -- PMM
