In this post I will explain how httpvnc sessions are created and served from the built-in web interface.
What happens when httpvnc is started
When you start up the httpvnc daemon, two things will happen:
- a session broker is started that listens on /var/run/httpvnc.sock
- a web server is started that listens on http://0.0.0.0:8080
Both parts of httpvnc use sessions. In order to distinguish between them, we will call them 'http session' (for sessions controlled by the web server) and 'desktop session' (for sessions controlled by the session broker).
The Web Interface
The web interface is the user access point. A user can login, create and manage sessions, and he can connect to running sessions using either a Java applet or a HTML5 canvas object. As with all user interfaces, the first step is to login. If the username and password supplied by the user are valid, the browser will receive an http session cookie that is needed in order to be able to use the web interface. If the cookie becomes invalid or is lost, the user will have to login again.
The web interface uses existing Unix user accounts in order to authenticate users, because the desktop sessions will run under these user accounts. As a security measure, only users belonging to group 'httpvnc' are allowed to login.
Besides the http session cookie, every running desktop session has an id, too. As long as a user (browser) knows this session id, and the http session cookie is valid, the user may reconnect to the running desktop session without supplying any further credentials.
This operation mode opens up a possible security hole: if any logged in user should ever get to know a desktop session id of another user, he or she will be able to connect to this session without any further authentication. However, getting to know any foreign ids is difficult (apart from inspecting the contents of another person's browser, which should be difficult, too). We will further secure things in a future release by starting to use VNC passwords and one-time session keys that are internally mapped to the "real" session key.
The Session Broker
The session broker is where all Unix (Linux) level tasks are performed: creating and deleting desktop sessions, authenticating users, and so on. For this, the session broker listens on /var/run/httpvnc.sock for incoming connections. Only processes belonging to group 'httpvncd' are allowed to connect to this socket.
Please be aware that any process belonging to httpvncd will be able to connect to running desktop sessions without supplying any further credentials once it gets to know any valid desktop session id. However, finding these session ids is again difficult, as they are only visible to the user (not group!) httpvnc (under which the web interface is running) and - of course - root.
In order to perform the necessary tasks, the broker must run as root. This makes the broker a very dangerous piece of software. You should NEVER put any other users in group httpvncd or play with the access rights of /var/run/httpvnc.sock unless you are very positively sure what you are doing.
How the Session Broker and the Web Interface Talk
The session broker and the web interface talk over the /var/run/httpvnc.sock socket. The protocol is very simple, and since the parser is even simpler (and thus very fragile), you shouldn't ever try to talk to this socket directly. If you want to control the functionality of httpvnc from any other software (e.g. your own web interface), please use the client functionality of httpvnc introduced in version 1.7. I will also post a blog entry on this topic later.
Session Persistence
The httpvnc daemon (i.e. the web interface and broker tasks) can be stopped at any time without interrupting any running desktop sessions. Once restarted, the daemon will recollect the running desktop sessions and serve them again.
An Example
Let's have a look at how things work in this example:
- The root user starts httpvnc (by running 'httpvnc start'). This spawns two processes: a web server listening on TCP port 8080 (running as user httpvnc), and a session broker listening on /var/run/httpvnc.sock (running as root). The web server can talk to the session broker, as it shares the group httpvncd with the socket file.
- A user connects to the webinterface. In the login mask, he enters a username and a password.
- The web server will now create an http session and connect to the broker. Both username and password are transferred to the broker along with the the client IP. If the credentials provided are ok, and the user is in group httpvnc, then the broker will also create an internal session key that the web server can use for further requests concerning this particular user (connected from this client IP).
- Now the web server shows a list of available sessions, plus a mask the user can start new sessions with. The list of available sessions is provided by the broker for this particular user.
- If the user clicks on an existing desktop session, the web server will again contact the broker and ask whether the user has the right to open this session. If the broker agrees, then the web server will return a HTML5 canvas object (or a Java applet, whichever was chosen by the user) with the according URL of this desktop session.
- If the user creates a new desktop session, the web server will ask the broker to create it. The broker will now spawn a couple of new processes running under the id of the user that requested the desktop session: one for the X server, another one for the display manager (FVWM), and possibly a couple of other applications, depending on the FVWM configuration. Then the desktop session id of this new session is returned to the web server, which will then return a HTML5 canvas object (or a Java applet) to the browser.
The HTML5 canvas object uses websockets in order to transfer VNC data. The Java applet on the other hand will simply hijack the HTTP stream of the first VNC request and start transferring VNC over it. While the HTML5 canvas object might have a chance of surviving things like proxies and firewalls (provided they like websockets), the Java stream will almost surely die if no direct connection is possible. However, the Java applet is considerably faster both in terms of user interaction/screen updates and data transfer.
It is important to understand that the broker does not have anything to do with the VNC protocol data transfer itself; once the web server knows a valid session id, it is able to connect to this particular session without any further restrictions, data transfer is completely handled by the web server. The same rule applies to any process running under group httpvncd that might be able to get hold of a valid desktop session id!