Top link
Programming in Haskell.
Programming in Haskell.

VirtualExam (vx)
Identifying exam sessions

When a student computer's X server connects to a backend exam server to run an exam, a number of things need to happen which only have to do with that particular computer-and-X-server, that particular student and that particular exam while similar things are happening on the same and other backend exam servers for other students sitting either different exams or the same exam.

How do we keep them all separate?

$DISPLAY and X11 cookie

Firstly, let's consider the computer in front of which the student will sit, and the X server which runs on it.

Before the student has even sat down, the X server connects to the backend exam server and establishes an X11 session to carry screen updates, and mouse and keyboard events.

This connection is identified, at the backend exam server, by the $DISPLAY environment variable. A unique X11 so-called cookie is also associated with this connection by the X server itself. X11 clients which attempt to connect to this X server session which don't have the correct cookie are given the boot. The cookie is, in effect, a shared secret used for authentication.

Because multiple students will be sitting the same exam at the same time, and because this involves their computer/X server ssh-ing in to a backend server using the credentials of the same class exam account, we potentially have the problem that all the students doing the same exam on the same backend exam server will have access to the same cookie store (which is normally .Xauthority in the class exam account's home directory). Bummer!

To prevent this happening, and to help prevent other students' cookies and $DISPLAY's getting into any student's environment, we use a rarely-mentioned feature of sshd. This is the ~/.ssh/rc script. This script, when it exists, runs after a user's ssh login succeeds, but before their shell runs. What we do is use this script to snaffle the $DISPLAY and X11 cookie for a new exam session and store them away separately for each session and not allow them into the environment or default .Xauthority file at all.

Session ID and session directory ($SESSIONID and $SESSIONDIR)

To store the $DISPLAY and X11 cookie for each student's X11 exam session without confusion, we use the PID of the session leader.

Eh?

When someone logs in to a Linux (or any generic UNIX®) system, their login shell establishes itself as the session leader (see setsid()). It's PID becomes the session ID of all children in this particular session — i.e., this session ID is inherited by all the children started (exec'ed) in this session. The session ID can be read for any process.

This means that we can use this session ID to uniquely identify a student exam session's processes on a particular backed exam server, regardless of whether they are running as the class exam account, running from priv, or running in the gaol.

This session ID can be read from a shell script like this:

/bin/ps --no-heading -o sid --pid $$

If we then combine this session ID with the hostname of the particular backend exam server, we then have an ID which is unique across our whole exam 'universe'. And it can be done like this:

SESSIONID=`/bin/ps --no-heading -o sid --pid $$` || exit 1
SESSIONID="`hostname`-$(($SESSIONID + 0))"

The fiddle with "$(($SESSIONID + 0))" simply gets rid of a rogue white space left behind by the ps.

Now. To convieniently share information between all processes — inside or outside of the goal, and under priv — which are associated with each individual student exam session, we use a session directory, of which we have one per student exam session. It is available on all backed exam servers and its location is:

SESSIONDIR="/home/<class-exam-account>/var/$SESSIONID"

In other words, it's located in the class exam account's home directory in ~/var.

You can find a list of all the files which are stored in the session directory here.

Gaol location

The gaol is located on the backend exam server at:

/var/gaol/<student-zID>

Things we've discussed here