On 08/01/2016 10:14 AM, Daniel P. Berrange wrote: > On Mon, Aug 01, 2016 at 10:00:05AM -0600, Jim Fehlig wrote: >> On 08/01/2016 03:13 AM, Daniel P. Berrange wrote: >>> On Fri, Jul 29, 2016 at 02:16:16PM -0600, Jim Fehlig 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 >>> 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" :-). > It is the distinction between what auth method is configured, vs what > passwords are valid for the auth method. That an empty password is > blocking access is a characteristic of the auth method.
I see. Thanks for the explanation. > >>> 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:~> > To start rejecting it now would be a non-backwards compatible change in > our behaviour, so we can't really do that. Ah, right. I think that was mentioned in one of the threads discussing the patch. Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
