On 08/01/2016 03:13 AM, Daniel P. Berrange wrote:
I've noticed the behavior described by this LSN with libvirt+Xen. Config containing <graphics type='vnc' passwd=''/> allows any client to connect with no authentication check. I asked about this on the Xen security list and was told that "libxl interprets an empty password in the caller's configuration to mean that passwordless access should be permitted". The libvirt domXML docs are not clear on semantics of empty vnc password, only stating "The passwd attribute provides a VNC password in clear text".
Should the libvirt domXML vnc passwd documentation be amended to define the semantics of an empty string in the passwd attribute? Is the behavior hypervisor-dependent as the documentation in qemu.conf suggests? I guess we've never clarified the semantics in any cross-hypervisor manner. I think the fixed QEMU behaviour is the most sane from a
On Fri, Jul 29, 2016 at 02:16:16PM -0600, Jim Fehlig wrote: portability POV - the Xen (and broken QEMU) behaviour was effectively overloading 2 settings onto one attribute. ie it was (ab)using a zero length password as a way to change the authentication method.
I can't get past thinking the fixed QEMU behavior only changed the overloading of passwd from "disable auth" to "disable vnc access" :-).
We should always have distinct XML attributes for distinct settings. IOW, any toggle betweeen password and no-auth should an explicit setting and a zero length password should not magically change that.
Shouldn't an empty password simply be rejected? I can't set a zero-length password on my UNIX account jfehlig@talkeetna:~> passwd Changing password for jfehlig. (current) UNIX password: New password: <enter> BAD PASSWORD: it is WAY too short passwd: password unchanged jfehlig@talkeetna:~> Regards, Jiim