A Blast from the Past

In the early '80s, Rogue, a game that would overhaul the gaming world, was released. According to Roguelike Gallery, Rogue first ran on a PDP-11 machine running Unix v6 [1]. Primitive by today's standards, Rogue popularized the Roguelike genre despite not being the first game of its kind. Rogue's influence can be seen in modern commercial titles. Rogue's source code is still available, as are many games that pre-date Linux.

In this article, I show how to set up a server to host antique terminal games. Why would you want to do this? Besides preserving a piece of history, playing these games is fun despite their age. In addition, running games on a specific server allows you to keep scoreboards, letting you compete against friends on a shared server. Last, but not least, setting up a game server is an instructive exercise.

Service Architecture

This article assumes you are using Debian, which unlike early 16-bit Operating Systems, is capable of using modern connectivity protocols.

In the service architecture, openbsd-inetd takes an incoming Telnet connection from the user and passes it to a Telnet daemon (telnetd). The Telnet daemon calls dgamelaunch. Dgamelaunch chroots into /var/dgl and provides a limited shell that allows the user to play games (Figure 1).

Figure 1: The game server's service architecture.

The core of this game server is the game launcher, which is a limited shell that is used to authenticate the player and start games. The launcher I am using, dgamelaunch [2], is surprisingly capable for such a small C program. Dgamelaunch records games, allows users to watch other players, and relays messages from one person to another.

The game server will be available over Telnet, a ubiquitous protocol that most operating systems support out of the box. The idea is to let the player connect to the server using a Telnet client and offer him or her a dgamelaunch shell that will allow them to select which games to play. Beware: Telnet is not secure (see Upgrading from Telnet for a safer approach).

Chroot Security

Dgamelaunch uses chroot() as a security layer. Roughly speaking, when you chroot into a directory, you are running a process inside that directory, with the process viewing the directory as the root (/) of the filesystem hierarchy. In essence, it means any process running within the chroot cannot access files placed outside of the chroot directory. This makes chroot() a poor man's isolation technique. A server running within a chroot won't be able to wreak havoc in the rest of the filesystem if the service is compromised.

However, chroots are breakable by design, making them less than ideal for isolating a service from the rest of the operating system. A root-owned process within a chroot can create block device nodes. If a chroot includes a hard link that points to an external resource, the resource can be abused from within the chroot. Also, a root-owned process can break out of the chroot directory.

Consequently, chroot() is no substitute for proper privilege separation. To avoid this problem, dgamelaunch drops privileges immediately after chrooting. Unprivileged processes can't escape from a chrooted environment so easily.

Installing dgamelaunch

Unfortunately, dgamelaunch is not packaged by any major Linux distribution. At the time of writing, the project has had no official release since 2011. However, dgamelauch is used by many current projects, including Roguelike Gallery, Dungeon Crawl Stone Soup [3], and the public NetHack server NAO [4]. As a result, there is a constant influx of patches from the community should you ever need them, despite the official project appearing to be dead.

The following command (which must be run as superuser) installs everything you need in order to compile dgamelaunch:

# apt-get install automake autoconf build-essential git bison sqlite3 libsqlite3-dev curl unzip groff libncurses-dev flex-old

You can get the source code from GitHub using the following command:

$ git clone https://github.com/paxed/dgamelaunch.git

Then, compile the program. If you intend to enable sqlite for managing your users and plan to use /var/dgl as a chroot directory, you may configure and compile dgamelaunch as follows:

$ cd dgamelaunch
$ ./autogen.sh --enable-sqlite --enable-shmem --with-config-file=/var/dgl/etc/dgamelaunch.conf
$ make

This prepares dgamelaunch to load its configuration from /var/dgl/etc/dgamelaunch.conf and to use sqlite as the user database.

Next, build the chroot directory that dgamelaunch will switch into when a user connects to the server. Dgamelaunch provides a script, dgl-create-chroot, to do this. Open dgl-create-chroot with any text editor and change the configuration variables to your liking. The script is NetHack-centric, because NetHack is the most popular Roguelike game in existence, but you can leave the NetHack-related variables unmodified if you don't plan to run it at all. See Listing 1 for the variables you can set.

CHROOT="/var/dgl/"
USRGRP="games:games"
SQLITE_DBFILE="/dgldir/dgamelaunch.db"
# Leave this variable empty to skip installing gzip in the chroot
COMPRESSBIN=""
# The script is Nethack centric. Leave some variables blank since
# we have no use for them.
NETHACKBIN=""
NH_PLAYGROUND_FIXED=""
# There Nethack related variables must be set even if we have no
# use for them.
NHSUBDIR="/nh343/"
NH_VAR_PLAYGROUND="/nh343/var/"

Once the configuration is done, save the script and run it as root:

# bash dgl-create-chroot

If you use the example values from Listing 1, the /var/dgl directory will be created and populated with all the necessary libraries and configuration files to run a chroot.

Finally, install dgamelaunch in /usr/bin, with the setuid bit set.

# cp dgamelaunch /usr/bin/
# chmod 4755 /usr/bin/dgamelaunch