VLAB shared sessions

Introduction

Up until now, standard VLAB sessions have been unshareable. That is, only the user who started a session could see the VLAB session/desktop and it wasn't possible to share the session with other users.

We are now trialling VLAB sessions which can be shared with other users. What this means is that once you start up a VLAB session you can then allow other users to view and even interact with your session.

How it works

Apart from the sharing capability, shared VLAB sessions work much the same as ordinary VLAB sessions. To start a shared VLAB session, instead of connecting to vlab.cse.unsw.edu.au:59xx (where xx indicates the session window size) you connect to:

vlabshare.cse.unsw.edu.au:5991 (size = 1154 x 896)
OR
vlabshare.cse.unsw.edu.au:5992 (size = 1024 x 768)
OR
vlabshare.cse.unsw.edu.au:5993 (size = 800 x 600)

You then get a normal VLAB session where you log in as usual and which works as usual.

Note that initially your session is not sharable by anyone.

To activate sharing

vlabsharing control program

Run the program vlabsharing. This pops up a window with sharing controls (see right).

Note the "Guests connect to:" setting. When sharing is turned on, other users can connect to your session using a normal VNC client with these settings.

There are three sharing modes:

  • Password only (the startup setting). If a user tries to connect to your session they'll get prompted for a password. The password file, as you can see in the window, is initially set to /dev/null and so no password will succeed.

    The /usr/local/tigervnc/usr/bin/vncpasswd can be used to create a password file (which needs to be readable by "nobody" so you'll probably have to make it world readable). You can create two passwords with this program - one is a read/write/interactive password, and the other is a view-only password (which is what you'd hand out to people if you only want them to view what you're doing such as when you're doing demonstrations). Note that while the password file contents are encrypted the password security is weak and, in any case, if you're handing out passwords to swathes of other people then you can't really expect for them not to leak anyway.

    You can change the password file whenever and how often you want during a session and the change becomes effectively immediately, however people who have already got access won't be affected by any changes. Thus, after all of your guests have arrived you might want to reset the password file to /dev/null or, for quick typing, to the name of a non-existent file such as "x" (assuming that's the case for you). This will prevent new people connecting.

  • Sharing prompt
  • Confirm only. This pops up a window each time someone tried to share your session (i.e., connect to it) and you can either accept or reject their attempt (see right). You don't have to set up passwords to use this, but it is probably only suitable when you're sharing with one or two other people.

    Password-based sharing probably would be better for larger numbers of guests (e.g., tutorials or lectures) because you don't have to do anything to allow users to connect except tell them, a priori, a password (probably the view-only one). Your guests can then come and go as they please without bothering you.

  • Password plus confirm. This is a combination of the above so connectees need to know a password and also then need to be accepted each time they try to connect.

Notes

  • The TigerVNC client supports all sharing modes.
  • A small number of VNC client programs don't support either of the confirm sharing modes. However, password-only mode will work with all clients.
  • The first client of a session, the one which created the session by connecting to vlabshare.cse.unsw.edu.au, is the master client. When this client disconnects, the session shuts down immediately, regardless of whether any other users are sharing it.
  • When you share your session, the people you allow in will be operating the session AS YOU. Thus, they'll have access to all your files and can run programs as you so, from a security point of view, don't walk away while there's anyone sharing your session.
Last edited by plinich 09/05/2018