Would like to have unix-socket-attaching

[Anon S. <an...@vi...>]

(I'm not sure my last emails reach the list, because I can't recieve my
own posted message.  I apologize for those who receive this email twice
or more)

On 20 Oct 2004, Constantin Kaplinsky wrote:

> Hello Anon,
>
> >>>>> "AS" == Anon Sricharoenchai <an...@us...> writes:
>
> AS> In the CVS, http://cvs.sourceforge.net/viewcvs.py/vnc-tight/
>
> AS> tightvnc/
> Future TightVNC versions based on RealVNC4 (not functional at this
> moment).
>
> AS> tightvnc-unix/
> AS> tightvnc-win32/
> These two will be dropped. They include modifications that will be
> ported to the tightvnc/ tree.
>

Ok, I'm interesting in contributing my patch to TightVNC.
Then I should create the patch against this RealVNC4-based tree, is that right?

I've just created the patch over the RealVNC 4.0 (official release).
My patch is to add the unix socket attaching features on VNC system.
The basic feature is to have VNC communicating via the unix socket file.
This feature is very useful to develop VNC application with the behavior like
in the program called "screen".  With these features, the VNC can be further
developed to be easy to use as the windows terminal service (or remote desktop
protocol (RDP)) system.

These features also introduce a new approach to implement ssl support on RFB
without any ssh tunneling.  This ssl support is just a by-product feature,
since it requires a minor adaptation of those unix socket features to have ssl
support.

The patch is available at,
http://linux.thai.net/plone/Members/ans/release/EasyVNC/vnc-4.0-unixsrc.unix-socket-attaching.2004-10-17.patch
(Visit http://linux.thai.net/plone/Members/ans/release/EasyVNC/ for other stuff
related to the patch).

The following is a complete README of my patch, available from
http://linux.thai.net/plone/Members/ans/release/EasyVNC/README.unix-socket-attaching.2004-10-18.txt
(I hope the TightVNC project can accept my patch after reading this article).


This patch for realvnc is aimed to have some features in communicating
RFB protocol via a unix socket file.  Communicating this way is useful to
create VNC application with a behavior like a program called "screen".  With
these features, it can be further developed to be easy to use as the windows
terminal service (or remote desktop protocol (RDP)) system.  These features
also introduce a new approach to implement ssl support on RFB (by now, only
support on UNIX system) without any ssh tunneling.  Now, let's see how it work.


Understanding the idea from its root
====================================
This patch introduces the new features in VNC on a UNIX-like system.  The first
is the fundamental feature of "vncviewer" and "Xvnc", in connecting to and
listening on the unix socket file, respectively.  For example,

   $ rm -f /tmp/v1.socket
   $ Xvnc :1 -unixSocket=/tmp/v1.socket -securityTypes=None &

By this command, "Xvnc" will listen on the unix socket path, "/tmp/v1.socket",
rather than on the internet socket.  To connect to that unix socket path,

   $ vncviewer unix/:/tmp/v1.socket

where "unix/" specifies the transport type.  If not specified, the default
transport type will be "auto/".  The "auto/" transport type will first try the
conventional "tcp/" transport type, and then other appropriate transport type
which will be described later (This transport format is setup from the idea of
the font path format in the X windows system).

The use of this unix socket will allow the VNC client to attach (locally) to
the VNC server via unix socket path.  This connection will be secure without
the need of any RFB authentication, because the security will be setup using
the owner and permissions of that unix socket path.

By this idea, it can be further improved to have the ability to securely attach
to the VNC server (that listening on some unix socket file) on remote machine
over the network via "ssh" command.  The idea is to get the RFB connection on
the remote machine via "ssh" standard input/output.  So "vncviewer" is required
to have the ability to connect to the RFB via "ssh" (or any command) standard
input/output (This ability can be compared to the "--plugin" options of the
"fetchmail" program).  The transport type, "stdio/", is then designed for this
requirement.

   $ vncviewer stdio/:"<command> <args>"
   $ vncviewer stdio/:"ssh -x -C -T user@remote_host <remote command>"

The <remote command> will be the command on the remote_host that attach the
unix socket file (currently listened by some VNC server on that host) to the
"ssh" standard input/output, so that "vncviewer" can continue to communicate
the RFB protocol on those standard input/output.

The next task is to implement the command that attach the unix socket file to
the standard input/output on the remote host.  I've chosen the existing
"vncserver" script to do this task, by adding the option "-attach".  On the
remote host,

   $ vncserver -attach -unix :1
   RFB 003.008

The script will attach the unix socket path, $HOME/.vnc/host:1.socket, to the
standard input/output.  The "-unix" option is to tell it to attach to the unix
socket (If no "-unix" option specified, the script will first try to attach to
the conventional TCP socket on local VNC port (5901 in this case), and then try
the unix socket path, if the requested TCP port is not available).  The command
to connect VNC on remote host, then, can be,

   $ vncviewer stdio/:"ssh user@remote_host -x -C -T vncserver -attach -unix :1"

   VNC viewer for X version 4.0 - built Oct 13 2004 15:33:07
   Copyright (C) 2002-2004 RealVNC Ltd.
   See http://www.realvnc.com for information on VNC.

   Wed Oct 13 18:35:00 2004
    CConn:       connected via command 'ssh user@remote_host -x -C -T vncserver
                 -attach -unix :1'
   user@remote_host's password: <key ssh password here>

   Wed Oct 13 18:35:01 2004
    CConnection: Server supports RFB protocol version 3.8
    CConnection: Using RFB protocol version 3.8
    TXImage:     Using default colormap and visual, TrueColor, depth 24.
    CConn:       Using pixel format depth 6 (8bpp) rgb222
    CConn:       Using ZRLE encoding

Specifying the above "vncviewer" options is too long, so another transport type
named "ssh/" was added.

   $ vncviewer ssh/user@remote_host:1

   VNC viewer for X version 4.0 - built Oct 13 2004 15:33:07
   Copyright (C) 2002-2004 RealVNC Ltd.
   See http://www.realvnc.com for information on VNC.

   Wed Oct 13 18:39:43 2004
    CConn:       connected to host user@remote_host:1, via ssh
   user@remote_host's password: <key ssh password here>

   Wed Oct 13 18:39:45 2004
    CConnection: Server supports RFB protocol version 3.8
    CConnection: Using RFB protocol version 3.8
    TXImage:     Using default colormap and visual, TrueColor, depth 24.
    CConn:       Using pixel format depth 6 (8bpp) rgb222
    CConn:       Using ZRLE encoding
    CConn:       Throughput 1595 kbit/s - changing to full colour
    CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
    CConn:       Throughput 3178 kbit/s - changing to hextile encoding
    CConn:       Using hextile encoding

The "ssh/" transport will do all things necessary to attach to the remote_host,
that is equivalent to the use of,

   $ vncviewer stdio/:"ssh user@remote_host -x -C -T vncserver -attachonly :1"

The option "-attachonly" to the "vncserver" script is like "-attach" except
that it will not create any new VNC session.

Notes that the command "vncserver -attach -unix :1" will also create the new
VNC session, ":1" (listening on the unix socket path,
$HOME/.vnc/host:1.socket), before attaching to that session, if the session
doesn't exist or haven't yet been created (Notice that this is the basic task
of the original "vncserver" script).  The option "-attachonly" will be used to
force the script not to create a new VNC session, eventhough the session
doesn't exist.

Note: The "-attachonly" option implies the "-attach" option.
Note: The command "vncserver -unix :1" will create new VNC session listening on
      unix socket file, without attaching it to the standard input/output.

Applying the option "-createSession" to "vncviewer" command will tell the
remote host to auto create the new VNC session (on the first connection), by
passing the option "-attach" (rather than "-attachonly") to "vncserver"
script.  Then the command,

   $ vncviewer -createSession ssh/user@remote_host:1

is equivalent to,

   $ vncviewer stdio/:"ssh user@remote_host -x -C -T vncserver -attach -unix :1"

(Notice that it also pass the "-unix" option to force it to create session
listening on a unix socket file, rather than TCP socket.  Without
"-createSession", it will pass to "vncserver" the option, "-attachonly" without
"-unix" option, for the script to auto detect the transport type that the
(existing) requested session is currently listening on).  Now, let's see how
"-createSession" work,

   $ vncviewer -createSession ssh/user@remote_host:1

   VNC viewer for X version 4.0 - built Oct 14 2004 10:23:45
   Copyright (C) 2002-2004 RealVNC Ltd.
   See http://www.realvnc.com for information on VNC.

   Thu Oct 14 10:48:32 2004
    CConn:       connected to host user@remote_host:1, via ssh
   user@remote_host's password: <key ssh password here>

   New 'remote_host:1 (remote_host)' desktop is remote_host:1

   Starting applications specified in /home/user/.vnc/xstartup
   Log file is /home/user/.vnc/user:1.log


   Thu Oct 14 10:48:38 2004
    CConnection: Server supports RFB protocol version 3.8
    CConnection: Using RFB protocol version 3.8
    TXImage:     Using default colormap and visual, TrueColor, depth 24.
    CConn:       Using pixel format depth 6 (8bpp) rgb222
    CConn:       Using ZRLE encoding

The above command tells the remote_host to create and attach to the VNC
session, ":1".

To be more convenient, the "auto/" transport type was introduced.  This
transport will try to detect the current transport type the server are
listening to.  It will first try to connect using the conventional "tcp/"
transport type.  If the "tcp/" transport fail, it will do the next step.

Note: The connection address "auto/remote_host:1" is equivalent to
      "tcp/remote_host:1", if the server is listening on the appropriate VNC
      port of the "tcp/" transport.

In "auto/" transport mode, if the "tcp/" transport of the requested session is
not available, it will then connect using "ssh/" transport.

   $ vncviewer auto/remote_host:1

   VNC viewer for X version 4.0 - built Oct 13 2004 19:26:34
   Copyright (C) 2002-2004 RealVNC Ltd.
   See http://www.realvnc.com for information on VNC.

   Wed Oct 13 20:17:14 2004
    CConn:       connected to host remote_host:1, via ssh
   user@remote_host's password: <key ssh password here>

   Wed Oct 13 20:17:16 2004
    CConnection: Server supports RFB protocol version 3.8
    CConnection: Using RFB protocol version 3.8
    TXImage:     Using default colormap and visual, TrueColor, depth 24.
    CConn:       Using pixel format depth 6 (8bpp) rgb222
    CConn:       Using ZRLE encoding

Note: The connection address "auto/remote_host:1" is equivalent to
      "ssh/remote_host:1", if the server is not listening on the "tcp/"
      transport.

Specifying the user name is also valid in "auto/" transport mode,

   $ vncviewer auto/user@remote_host:1"

Note: The connection address "auto/user@remote_host:1" is equivalent to
      "ssh/user@remote_host:1", if the server is not listening on the "tcp/"
      transport.

Using the "auto/" transport without specifying user@remote_host, for example,

   $ vncviewer auto/:1

or, if it is "localhost",

   $ vncviewer auto/localhost:1

will let "vncviewer" to attach itself, directly, via the local command,
"vncserver -attachonly :1" using "stdio/" transport, rather than via "ssh"
command in the "ssh/" transport.

   $ vncviewer auto/:1

   VNC viewer for X version 4.0 - built Oct 13 2004 19:26:34
   Copyright (C) 2002-2004 RealVNC Ltd.
   See http://www.realvnc.com for information on VNC.

   Wed Oct 13 19:33:54 2004
    CConn:       attached to :1
    CConnection: Server supports RFB protocol version 3.8
    CConnection: Using RFB protocol version 3.8
    TXImage:     Using default colormap and visual, TrueColor, depth 24.
    CConn:       Using pixel format depth 6 (8bpp) rgb222
    CConn:       Using ZRLE encoding
    CConn:       Throughput 21111 kbit/s - changing to hextile encoding
    CConn:       Throughput 21111 kbit/s - changing to full colour
    CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
    CConn:       Using hextile encoding

Note: The connection address "auto/:1" or "auto/localhost:1" is equivalent to
      stdio/:"vncserver -attachonly :1", if the server is not listening on the
      "tcp/" transport.

By default, if no transport type specified in the "vncviewer" command line, it
will assume the "auto/" transport.

To let the remote host to search for a new free session to create, use the
magic session number ":0" with "-createSession" option like this,

   $ vncviewer auto/user@remote_host:0 -createSession

or,

   $ vncviewer user@remote_host:0 -createSession

   VNC viewer for X version 4.0 - built Oct 14 2004 10:23:45
   Copyright (C) 2002-2004 RealVNC Ltd.
   See http://www.realvnc.com for information on VNC.

   Thu Oct 14 11:53:59 2004
    CConn:       connected to host user@remote_host:?, via ssh
   user@remote_host's password: <key ssh password here>

   New 'remote_host:1 (remote_host)' desktop is remote_host:1

   Starting applications specified in /home/user/.vnc/xstartup
   Log file is /home/user/.vnc/user:1.log


   Thu Oct 14 11:54:07 2004
    CConnection: Server supports RFB protocol version 3.8
    CConnection: Using RFB protocol version 3.8
    TXImage:     Using default colormap and visual, TrueColor, depth 24.
    CConn:       Using pixel format depth 6 (8bpp) rgb222
    CConn:       Using ZRLE encoding

Notes that when using ":0" connect to a win32 server, it will work as a usual
conventional "tcp/" transport (rather than working as a magic session), because
the "auto/" transport will detect the TCP connection first.


Strong point
============
The benefit of this connection paradigm (the connection via unix socket) are,
1. Secure connection : All conversation will be encrypted via secure shell.
2. Secure authentication : Authenticate using ssh password rather VNC password.
   The VNC system stores in the file, the password that is decryptable, while
   secure shell use the UNIX system password which is undecryptable.
3. Centralize authentication : No need to have seperate VNC password.  It use
   the same authentication system (via secure shell) as the UNIX authentication
   on the remote host.
4. Trust the session owner : When the user connect to his own sesssion on the
   same host, the client can connect to the unix socket file without any RFB
   authentication, because the one having the right permission on the socket
   file is trusted.  This then can get rid of the unnecessary authentication on
   his own userspace.
5. Easy to use : Using the option "-createSession" to "vncviewer" can tell the
   server to create the requested session before establishing the RFB
   protocol.  So, the users have no need to get some separate shells on the
   remote host to create a new session himself.
6. Future direction : This introduces the possibility to implement the session
   manager (as described below in "Future work" section) or something that is
   easy to use as a windows terminal service system.

Note: The item 4, 5, and 6 have some concepts alike to the concept of the
      "screen" program.


Weak point
==========
1. Only work on a UNIX-like system : Now, there's no any idea to implement VNC
   server with these mentioned features on a win32 system, but it is possible
   to implement a win32 client to have the "auto/" and "ssh/" connection to VNC
   server on a UNIX-like system.
2. No HTTP connection : For security reason, the HTTP connection will be
   disabled in unix socket listening mode, because the server side will be
   configured to have no RFB password.


Future work
===========
1. Implement the win32 client to support "auto/" and "ssh/" transport.  The
   "ssh/" transport may be implemented on win32 by merging the ssh client code
   (may be the code from "putty").
2. Implement VNC session manager to list all existing session upon connect.
   The session manager may be an X client program and the magic session ":0"
   may be used to display this program.  After the user have selected an
   session (available in the list), the session manager will then connect to
   that selected session (may be via another vncviewer program on the remote
   host.  Another approach is to tell the current display to attach itself to
   the requested session, alike to the concept in "screen" program in attaching
   the tty session).  Something that has the basic user-oriented behavior like
   the windows terminal service may be implemented.
3. Add to "vncviewer", the ability to pass some "Xvnc" specific options such
   as, "-geometry", "-depth", etc.


Appendix
========
The following is the summary of "vncviewer" transport type.

   $ vncviewer -h

   VNC viewer for X version 4.0 - built Oct 13 2004 19:26:34
   Copyright (C) 2002-2004 RealVNC Ltd.
   See http://www.realvnc.com for information on VNC.

   usage: vncviewer [parameters] [transport/][host:displayNum] [parameters]
          vncviewer [parameters] -listen [port] [parameters]

   The transport can be one of tcp, unix, stdio, ssh, or auto (default=auto)

     tcp/[host:displayNum] - The conventional transport type
     unix/:unixSocketPath  - The path to unix socket to connect and establish
                             the RFB protocol
     stdio/:commandLine    - Connect to the RFB protocol via the standard
                             input/output of this command line
     ssh/[[user@]host:displayNum] - Something like
                             stdio/:"ssh user@host vncserver -attach :displayNum"
     auto/[[[user@]host]:displayNum] - Auto detect

   Parameters can be turned on with -<param> or off with -<param>=0
   Parameters which take a value can be specified as -<param> <value>
   Other valid forms are <param>=<value> -<param>=<value> --<param>=<value>
   Parameter names are case-insensitive.  The parameters are:

     name           - The X window name (default=)
     MenuKey        - The key which brings up the popup menu (default=F8)
     DebugDelay     - Milliseconds to display inverted pixel data - a debugging
                      feature (default=0)
     CreateSession  - Create new VNC session, if the requested session does not
                      exist (default=0)
     display        - The X display (default=)
     geometry       - X geometry specification (default=)
     listen         - Listen for connections from VNC servers (default=0)
     SendPrimary    - Send the primary selection and cut buffer to the server as
                      well as the clipboard selection (default=1)
     SendClipboard  - Send clipboard changes to the server (default=1)
     AcceptClipboard - Accept clipboard changes from the server (default=1)
     Shared         - Don't disconnect other viewers upon connection - share the
                      desktop instead (default=0)
     ViewOnly       - Don't send any mouse or keyboard events to the server
                      (default=0)
     FullScreen     - Full screen mode (default=0)
     PreferredEncoding - Preferred encoding to use (ZRLE, hextile or raw) -
                      implies AutoSelect=0 (default=)
     LowColourLevel - Colour level to use on slow connections. 0 = Very Low (8
                      colours), 1 = Low (64 colours), 2 = Medium (256 colours)
                      (default=1)
     FullColor      - Alias for FullColour
     FullColour     - Use full colour - otherwise low colour level is used until
                      AutoSelect decides the link is fast enough (default=0)
     AutoSelect     - Auto select pixel format and encoding (default=1)
     DotWhenNoCursor - Show the dot cursor when the server sends an invisible
                      cursor (default=1)
     UseLocalCursor - Render the mouse cursor locally (default=1)
     passwd         - Alias for PasswordFile
     PasswordFile   - Password file for VNC authentication (default=)
     WMDecorationHeight - Height of window manager decoration around a window
                      (default=24)
     WMDecorationWidth - Width of window manager decoration around a window
                      (default=6)
     PointerEventInterval - Time in milliseconds to rate-limit successive pointer
                      events (default=0)
     Log            - Specifies which log output should be directed to which
                      target logger, and the level of output to log. Format is
                      <log>:<target>:<level>[, ...]. (default=)
     ZlibLevel      - Zlib compression level (default=-1)














-- 
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html