S&M at lug.org.uk: part 2

In my previous post, I talked about the Apache configuration for lug.org.uk’s Static and Managed (S&M) server. In this post, I’m going to talk about the patches and configuration needed to make DokuWiki work on it.

The S&M service is for hosting static web pages, and providing a set of web applications that we can deploy for individual LUGs to use. The first two apps we’re providing are DokuWiki and AbUseMod – the latter being based on UseMod wiki, and tweaked by HantsLUG to increase its anti-spam abilities.

Now, one of the problems with most web applications in use in the world today is that they’re written in various kinds of non-compiled languages, such as PHP and Perl. This means that the obvious and simple solution to configuring the application is to write the configuration file in the language the application is written in. So, a DokuWiki config file might look something like this:

Obviously, this is dead simple for the author, as they can then just use the $conf array in their code, and all is well. It’s a bit harder for us, because we’d have to allow the users to write their own config files, which means that the config files would have to be allowed to be executed, which means that a malicious user1 could simply put their own code into the config file. We therefore need to hack the applications we host so that the config files aren’t executable code.

The second problem we need to address is that most of these applications assume a separate copy of the application for each instance of it that’s running. This is problematic for us, because we want a centralised copy of the app, and multiple sets of configuration and data. This is, in general, rather easier to deal with than the first problem.

Non-executable config file

Of the two issues, this is the trickier to solve. The only way that we can prevent configuration files from being executed is to develop a new configuration file format, and write a parser for it that sets the relevant configuration properties. This has the advantage that we can limit the set of config options available to our users and prevent them from using configurations known to be insecure or otherwise problematic.

We can put this parser in the DokuWiki conf/local.php file and it will be picked up automatically. You can download the patch for it. The current version supports scalar types only, but will distinguish and validate several different datatypes, including enumerations. It is a trivial matter to add further “supported” configuration options to the parser, too.

Per-host data and configuration

The second issue, that of ensuring that every user has their own separate instance of the configuration and data files, is rather simpler to deal with. In the Apache configuration in my last article, there were two system variables set on a per-virtual-host basis: WIKI_NAME and WIKI_DATA. The former is simply used to set a default title for the wiki instance. The latter points at a user-specific directory where all the wiki content is stored for that user’s instance. The default configuration file described above uses WIKI_DATA to find the main configuration file and to set the location of the wiki data.

However, there are two other files, normally held in the conf/ directory, which need to be made per-instance. These are conf/acl.auth.php and conf/users.auth.php, and are used to define users on the wiki instance. Obviously, these also need to be made per-instance, rather than a global configuration, otherwise someone adding a user to Magnum Parva LUG would also add that user to all other LUGs. Fortunately, although these files have a .php extension, they’re not executed by the PHP engine but are simply read, parsed, and written directly by the DokuWiki code. Therefore, it is fairly simple to search for all occurrences of those filenames and patch DokuWiki to go looking in the WIKI_DATA directory.

Other applications

The only other web application we have running on S&M at the moment is the AbUseMod wiki, which has native support for a similar configuration. However, similar patches will need to be developed for each application we want to host on S&M. Some applications (e.g. Drupal) may not need much work done as they support multi-site hosting from a single base install. Others may be more problematic.

1. We haven’t yet had a malicious user on lug.org.uk, and I hope we won’t. However, in the case of a non-root compromise, it would be best to try to restrict the amount of damage possible.