I take your point about security, I'll do as follows.
- vnc_passwd is not omissible.
- The domain cannot be created if there is no vnc_passwd.
> On Thu, Aug 31, 2006 at 10:23:56AM +0900, Masami Watanabe wrote:
> > I'm thinking of adding the following protection to VNC console.
> > I know it's not perfect, nonetheless, it's far better than the current
> > no protection situation. Please comment.
> > Specification:
> > - The same challenge-response auth scheme as standard VNC to be available
> > from VNC viewer (like RealVNC).
> Yeah, looking at the various clients, challenge-response is the only one
> we can really rely on being present - in fact its the only one supported
> by Fedora VNC client (RealVNC IIRC?) at all.
> > - The vnc password of each VM is described in the VM configuration file.
> > When omit the password, do not use authentification.
> > ex) vnc_passwd = xxxxx
> I think we should be secure by default - if they omit the password then
> we should either generate one - and store it in xenstore, or refuse to
> activate VNC server. If we really really want to allow no passwords, then
> admin could have to explicitly request it with vnc_no_password=1
> in the config file - but my prefernce is still that we should flat out
> refuse to allow an empty password - in this day & day its just plain wrong.
> RealVNC server for example, refuses to allow empty password.
> > - Where "xxxxx" is an uuencoded encrypted password, that is,
> > you can get this value by
> > # cat ~/.vnc/passwd | uuencode -m passwd
> > (needs uuencode command: sharutils package)
> Perhaps base64 would be preferable - that's a standard part of Linux
> coreutils toolset, rather than an addon like uuencode is.
> |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
> |=- Perl modules: http://search.cpan.org/~danberr/ -=|
> |=- Projects: http://freshmeat.net/~danielpb/ -=|
> |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
> Xen-devel mailing list
Xen-devel mailing list