submit patch for realvnc, the feature to communicate via unix
socket
Anon Sricharoenchai
anons "at" users.sourceforge.net
Thu Oct 21 12:26:00 2004
Hi, realvnc developer team,
I would like to submit my patch for realvnc 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.
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).
Now, let's see how it work.
(I hope realvnc team can accept my patch after reading the following articles)
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 "at" 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 "at" 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 "at" remote_host -x -C -T vncserver
-attach -unix :1'
user "at" 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 "at" 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 "at" remote_host:1, via ssh
user "at" 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 "at" 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 "at" remote_host:1
is equivalent to,
$ vncviewer stdio/:"ssh user "at" 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 "at" 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 "at" remote_host:1, via ssh
user "at" 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 "at" 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 "at" remote_host:1"
Note: The connection address "auto/user "at" remote_host:1" is equivalent to
"ssh/user "at" remote_host:1", if the server is not listening on the "tcp/"
transport.
Using the "auto/" transport without specifying user "at" 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 "at" remote_host:0 -createSession
or,
$ vncviewer user "at" 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 "at" remote_host:?, via ssh
user "at" 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 "at" 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)