Multi v2.0

What is Multi?

Multi is a secure and configurable way to run CGI binaries on a WWW server. Multi is a wrapper for CGI execution. To create a secure environment, Multi will:
  1. Confirm the CGI can be run.
  2. Compare the CGI with the configurable Multi rule set.
  3. Reduce its privileges to a secure level.
  4. Run the CGI at the secured level.
  5. Do a configurable amount of logging.

Why Multi?

Until now, the only way to run secure CGI binaries was to submit them for review and installation. Every minor modification took additional time and resources to approve. Many sites disallowed CGI binaries to be run at all because of the inconvenience and risks. Now there is Multi. Once Multi is configured, CGI binaries can be created, modified, and executed without special assistance or security risks.

The Multi concept of security

A system without Multi can only execute a CGI with the permissions which the web server itself runs at. A single insecure binary could violate system integrity. Multi gains its security by extending the multiuser UNIX environment into the CGI paradigm. Each CGI is executed with the permissions of a special user ID. Every user ID has unique privileges and restrictions. These privileges and restrictions allow a CGI to work in an isolated environment which can not be accessed by the Web Server itself, nor other CGI binaries. Likewise, a CGI is restricted to a specific ID, so it can not overwrite files it is not permitted to.

A few of the Multi security precations

  1. Check for valid username.
  2. Removal of all groups that might have been added as a result of the httpdrunnign the cgi.
  3. Check to make sure user's shell is in /etc/shells.
  4. Recursive symlink checks.
  5. Invalid characters, also restricted characters in CGI pathname.
  6. CGI privlidge checks.
  7. Configurable amount of logging, from none to extensive.

Using Multi

First, Multi must be install in the proper directory where CGIs are run from on your server. It must be install with owner root, and permissions set to 4755.

It is then ready to be used. Its calling convention is:

and example is: Parameters can be passed to the CGI that Multi runs by adding them to the end of the URL that calls Multi, separating them by "+";

The Multi Configuration File Overview

The configuration file begins with global options. These are options that will be applied to the entire system unless individually overridden. The second part of the file contains directory segments and global overrides.

Each directory is specified via the directory directive. After the directory is specified, options can follow, which override the default options. If a user runs a CGI that is not not in a directory that that is specified as "allowed", then Multi will return an error message.

Configuration file directives

This option can only be used in the default/global section of the configuration file. With this option enabled, users may specify a path to Multi that start with a ~ such as: This will use the username that is between the ~ and the first / to determine all the necessary information. The home directory and UID information comes from /etc/passwd. When this option is taken advantage of, the UID that is used to run the CGI is of the owner of the directory that the CGI is in.

userdir directory_name
This option is another that may only be used in the default/global section of the configuration file. This option works along with homedirs. The directory_name that is passed to this option is inserted right after the first / after the username. For example, if userdir public_html and homedirs were in the configuration file, the following URL was given the following file would be executed as the CGI

Used to allow usage of CGIs in a directory. The following wild cards can be used:
Replaces a group of arbitrary characters until the next character after the * is found

Replaces any 1 (one) character.

Works exactly like *, except it uses what it finds as the username of the person running the CGI and grabs the UID to run the CGI as from the passwd file.

This is will be replaced by 1 (one) character. That character will then be matched to the username's Xth letter. If they do not match, it throws out the CGI's path as being invalid.

log options
Sets the level of logging. Options can be added together by specifying multiple options after log separated by whitespace. Options are:
all Logs everything
none (default) No logging
url Logs the URL of the CGI that was accessed successfully.
failure Logs all failures.
symlink Logs the URL of the CGI which included a symlink in its path and was successfully accessed.

uid the_uid
sets the UID to run CGI in to the_uid

gid the_gid
sets the GID to run CGI in to the_gid

symlink option
Set how symlinks are to be handled. Default is always. Options are:
always Always follow symlinks.
never Never follow symlinks.
ownersmatch Only follow symlinks if the owners match. (recursively)

badchars str1:str2:...:strN
Set what substrings or characters are invalid to use in CGI paths. Each string is separated by a ":". Common examples would be "/../", "/./", and "\".

Normally, root is not allowed to run CGIs through multi, this allows it.

Sample Multi configuration file


badchars /../:/./:\:~
uid www
gid private
userdir public_html

directory /home/%c1/%u/public_html
symlink never
log all
gid users

directory /staff/%u/public_html /staff/adm/%u/public_html
symlink ownersmatch
log failure
gid staff

directory /public_html
symlink always


  1. The first 5 lines are defaults. They will used for all CGIs unless something overrides them.
  2. Line 4 allows user to use the ~user convention. Line 5 inserts public_html after their username.
  3. The 7th line allows users to run CGIs from /home/%c1/%u/public_html* as long as the %u is a valid username and the subdirectory of the user directory is one letter long and matches the first letter of their username. The UID used here is from the %u.
  4. Lines 8-10 override or set new options for that one directory.
  5. Line 12 sets up 2 new directories with lines 13-14 as new or overriding-default options. The UID is used from the %u in both directories. If one or neither did not have a %u, it would use the default, which is user "www".
  6. Line 16 sets up a directory that is always run as UID www and GID private. The last 2 lines allow CGIs to be run as root, and to always follow symlinks in /public_html.

Back Copyright © 1995 Ishiboo!