CGI module

CGI/1.1 support

Overview
The CGI Interface is a popular means of creating dynamic content on the web. Zeus Web Application Server fully supports the CGI/1.1 specification. The CGI module is responsible for invoking CGI programs, passing input to them and returning their output.

Reference

Configuration

ACCESS CONTROL

For improved security on a webserver hosting many different users' homepages, many people restrict CGI programs to only those in designated directories. This way a webmaster can ensure that only programs that he/she has put into these directories are available to users. Such directories can be setup by the map module.

Alternatively, the CGI module may be configured to execute any file in the documentation tree with the correct MIME type (of application/x-httpd-cgi) as a CGI script. This is generally much more convenient.

Select which option is required and click on "Update" to use the new settings.

ENVIRONMENT VARIABLES

CGI programs receive some of their information from environment variables which are set by the CGI module. Additional environment variables can be set from the CGI Configuration page.

Enter the variable name and value into the text fields and click on the "add" button. The new variable will be passed to the CGI program when it is invoked. To delete a set variable, click on the "delete" button.

SANDBOXING

CGI programs run as individual, unique processes, this can result in problems when a CGI script is badly written or receives data different to that it was expecting. In these cases a CGI can claim excessive amounts of system resources. If your server machine is spending most of it's time processing CGI programs its HTTP performance will suffer. The situation is compounded with a large number of virtual servers, where a single virtual server could be responsible for ninety percent of CGI usage. CGI Sandboxing allows limits to be placed on the amount of resources a virtual servers CGI programs can consume.

CGI Sandboxing resource restrictions depend on the implementation of the ulimit system call within the operating system. Some operating systems fully support all options, some only a subset, and some none at all. For more details consult your operating system documentation.

Ulimit Configurables

Max CPU time: Sets the maximum amount of CPU time a process can consume. This provides a means to restrict large CGI process from monopolising the servers CPU.
Max Address space: Sets the maximum address space each each CGI process. This is the total amount of memory the process can use. Setting a small limit will only allow small CGI programs to be run. Small limits are suitable for sites which have compiled CGI programs, however interpreted CGI scripts will need larger limits.
Max data segment: Sets the maximum data segment for each CGI process. This is the maximum amount of space a process can use for its internal data structures. A small value restricts a badly written CGI program from claiming large amounts of memory.
Max processes available to CGI user: Sets the total number of available processes of the user who invoked the CGI program. This can be used to effectively limit the total number of CGI processes running at one time, or the total number of allowed CGI processes for each virtual server (providing each virtual server's CGI programs run as a different user). You should be aware that a CGI program could fork multiple copies of itself each time it's called, thus the maximum number of CGI processes may not be the same as the maximum number of CGI programs.

If you intend to use the CGI Sandbox environment you should consult the ulimit(1) man page for your system.

Security Configurables

Additional security limits can be placed on CGI programs, by changing the user id of the invoked CGI processes. Having different CGI users for different virtual servers allows different ulimit configuration options to be applied. You can be assured that a CGI process on one virtual server will not interfere with another on a different server. Using individual user id's for each virtual servers CGI processes can also assist system monitoring and performance analysis. If ulimit is not implemented in your Operating System, you can still run CGI programs as different users, but will not be able to apply different resource limits.

There are two methods of setting a CGI processes user id. Application server can either :

If you allow users to have CGI programs within their home directories the file system option may be useful, however you should ensure that no system wide CGI programs are owned by root.

If no CGI ownership options are configured the CGI process will be owned by the user which Application Server runs as. For details of this see the associated documentation

Application Server can also make use of the UNIX chroot command to restrict a CGI process to a limited sub section of the file system. This can ensure that a CGI program does not (by design or otherwise) leak sensitive system information from the server machine. If enabled, chroot the CGI program will be started, with the directory it resides in as the root of the file system. This leads to greater security, but also additional administration. CGI programs will often require additional components such as interpretors or shared libraries. You may need to install a minimal root file system within the CGI directory. For more details see the chroot man page.

To take advantage of the CGI Sandbox options you will need to start the webserver as root.

Enter the values documented above into the text fields and click on the "update" button to commit the changes. A value of "0" allows no CGI restrictions.