Chapter 8
Using CGI

Common Gateway Interface (CGI) programs run on the server and generate a response to return to the requesting client. CGI programs can be written in various languages, including C, C++, Perl, and as shell scripts. CGI programs are invoked through URL invocation.

A myriad of information about writing CGI programs is available. A good starting point is “The Common Gateway Interface” at:

http://hoohoo.ncsa.uiuc.edu/cgi/overview.html

Sun ONE Application Server complies with the version 1.1 CGI specification.

Since the server starts up a process each time the CGI script or program runs, this is an expensive method of programming the server.

For security, CGI scripts depend on the server’s security configuration. For more information, see “Security for SHTML and CGI” and the Sun ONE Application Server Administrator's Guide to Security.

This chapter includes the following topics:

CGI and J2EE Web Applications
Enabling CGI
Creating Custom Execution Environments for CGI Programs (UNIX only)
Adding CGI Programs to the Server
Setting the Priority of a CGI Program
The Query Handler
Perl CGI Programs
Global CGI Settings
CGI Variables

---

CGI and J2EE Web Applications

In Sun ONE Application Server, CGI programs cannot interoperate with J2EE web applications. Specifically:

Do not place CGI programs within web application context roots.
Do not include the output of CGI programs in servlets or JSPs.
Do not forward requests to CGI programs from servlets or JSPs.
You cannot apply J2EE security-constraint and filter-mapping features to CGI programs.

---

Enabling CGI

Sun ONE Application Server provides these ways to identify CGI programs:

Specifying CGI Directories. The server treats all files in CGI directories as CGI programs.
Specifying CGI File Extensions. The server treats all files with the specified extensions as CGI programs.

Specifying CGI Directories

To specify directories that contain CGI programs (and only CGI programs):

Create the CGI directory on your computer. This directory doesn’t have to be a subdirectory of your document root directory. This is why you must specify a URL prefix in Step 7.
Open the HTTP Server component under your server instance in the Administration interface.
Go to the Virtual Servers page.
Click on the name of the virtual server for which you are specifying a CGI directory.
Click on the CGI tab.
Click on the CGI Directory option.
In the URL Prefix field, type the URL prefix to use for this directory. That is, the text you type appears as the directory for the CGI programs in URLs.

For example, if you type cgi-bin as the URL prefix, then all URLs to these CGI programs have the following structure:

http://yourserver.domain.com/cgi-bin/program-name

Note	The URL prefix you specify can be different from the real CGI directory you specify in the previous step.

In the CGI Directory text field, type the location of the directory as an absolute path.
Click on the OK button.
Go to the server instance page and select the Apply Changes button.

The server treats all files in these directories as CGI programs.

To remove an existing CGI directory, click that directory’s Remove button in the CGI Directory page. To change the URL prefix or CGI directory of an existing directory, click that directory’s Edit button.

Copy your CGI programs into the directories you’ve specified. Remember that any files in those directories are processed as CGI files, so don’t put HTML files in your CGI directory.

For each CGI directory, the file obj.conf contains a NameTrans directive that associates the name cgi with each request for a resource in that directory. These directives are automatically added to obj.conf when you specify CGI directories in the Administration interface, or you can manually add them to obj.conf if desired.

For example, the following instruction interprets all requests for resources in http://server-name/cgi-local as requests to invoke CGI programs in the directory C:/SunServer/docs/mycgi.

NameTrans fn="pfx2dir" from="/cgi-local" dir="C:/SunServer/docs/mycgi" name="cgi"

The obj.conf file must contain the following named object:

<Object name="cgi"> ObjectType fn="force-type" type="magnus-internal/cgi" Service fn="send-cgi" </Object>

Do not remove this object from obj.conf. If you do, the server will never recognize CGI directories, regardless of whether you specify them in the Administration interface or manually add more NameTrans directives to obj.conf.

Specifying CGI File Extensions

To instruct the server to treat all files with certain extensions as CGI programs, regardless of which directory they reside in:

Open the HTTP Server component under your server instance in the Administration interface.
Go to the Virtual Servers page.
Click on the name of the virtual server for which you are specifying CGI file types.
Click on the CGI tab.
Click on the CGI File Type option.
From the Editing picker, choose the resource you want this change to apply to.
Click the Yes radio button under Activate CGI as a File Type.
Click on the OK button.
Go to the server instance page and select the Apply Changes button.

The default CGI extensions are .cgi, .bat and.exe.

To change which extensions indicate CGI programs, modify the following line in mime.types to specify the desired extensions. Be sure to restart the server after editing mime.types.

type=magnus-internal/cgi exts=cgi,exe,bat

When the server is enabled to treat all files with an appropriate extensions as CGI programs, the obj.conf file contains the following Service directive:

Service fn="send-cgi" type="magnus-internal/cgi"

---

Creating Custom Execution Environments for CGI Programs (UNIX only)

Before you can create a custom execution environment, you must install the suid Cgistub and run it as root:

Log in as the superuser.

su

Create the private directory for Cgistub:

cd instance_dir

mkdir private

Copy Cgistub to the private directory:

cd private

cp install_dir/lib/Cgistub .

Set the owner of private to the server user:

chown username .

Set the permissions on private:

chmod 500 .

Set the owner of Cgistub to root:

chown root Cgistub

Set the permissions on Cgistub:

chmod 4711 Cgistub

You can give each reference to the send-cgi function in obj.conf a user parameter. For example:

Service fn="send-cgi" user="username"

You can use variable substitution. For example, in server.xml, give a virtual-server element the following property subelement:

<property name="user" value="username"/>

This lets you write the send-cgi function line in obj.conf as follows:

Service fn="send-cgi" user="$user"

For more information about send-cgi and obj.conf, see the Sun ONE Application Server Developer’s Guide to NSAPI. For more information about server.xml, see the Sun ONE Application Server Administrator’s Configuration File Reference.

Restart the server so these changes take effect.

Note	You should install Cgistub in the instance_dir/private directory. If you install it anywhere else, you must specify the path to Cgistub in the init-cgi function in init.conf. For details, see the Sun ONE Application Server Developer’s Guide to NSAPI.

Note	It may not be possible to install the suid Cgistub program on an NFS mount. If you wish to use an suid Cgistub, you must install your server instance to a local file system.

Cgistub enforces the following security restrictions:

The user the CGI program executes as must have a uid of 100 or greater. This prevents anyone from using Cgistub to obtain root access.
The CGI program must be owned by the user it is executed as and must not be writable by anyone other than its owner. This makes it difficult for anyone to covertly inject and then remotely execute programs.
Cgistub creates its UNIX listen socket with 0700 permissions.

Note	Socket permissions are not respected on a number of UNIX variants, including current versions of SunOS/Solaris. To prevent a malicious user from exploiting Cgistub, change the server’s temporary directory (using the init.conf TempDir directive) to a directory accessible only to the server user. For details, see the Sun ONE Application Server Administrator’s Configuration File Reference.

After you have installed Cgistub, you can create custom execution environments in the following ways:

Specifying a Unique CGI Directory and UNIX User and Group for a Virtual Server
Specifying a Chroot Directory for a Virtual Server

Specifying a Unique CGI Directory and UNIX User and Group for a Virtual Server

To prevent a virtual server’s CGI programs from interfering with other users, these programs should be stored in a unique directory and execute with the permissions of a unique UNIX user and group.

First, create the UNIX user and group. The exact steps required to create a user and group vary by operating system. For help, consult your operating system's documentation.

Next, follow these steps to create a cgi-bin directory for the virtual server:

Log in as the superuser.

su

Change to the virtual server directory.

cd vs_dir

Create the cgi-bin directory.

mkdir cgi-bin

chown user:group cgi-bin

chmod 755 cgi-bin

You can set the virtual server’s CGI directory, user, and group in one of these ways:

Use the dir, user, and group parameters of the send-cgi function in the obj.conf file. For more information, see the Sun ONE Application Server Developer’s Guide to NSAPI.
Enter this information using the Administration interface:
Open the HTTP Server component under your server instance.
Go to the Virtual Servers page.
Click on the name of the virtual server for which you are specifying CGI directories.
Click on the General tab.
Type values in the Directory, User, and Group fields.
Click on the Save button.
Go to the server instance page and select the Apply Changes button.

For more information, see the Sun ONE Application Server Administrator’s Guide.

Specifying a Chroot Directory for a Virtual Server

To further improve security, these CGI scripts should be prevented from accessing data above and outside of the virtual server directory.

First, set up the chroot environment. The exact steps required to set up the chroot environment vary by operating system. For help, consult your operating system’s documentation. The man pages for ftpd and chroot are often a good place to start.

These are the steps required for Solaris versions 2.6 through 8:

Log in as the superuser.

su

Change to the chroot directory. This is typically the vs_dir directory mentioned in the previous section.

cd chroot

Create tmp in the chroot directory:

mkdir tmp

chmod 1777 tmp

Create dev in the chroot directory:

mkdir dev

chmod 755 dev

List /dev/tcp, and note the major and minor numbers of the resulting output. In this example, the major number is 11 and the minor number is 42:

ls -lL /dev/tcp

crw-rw-rw- 1 root sys 11, 42 Apr 9 1998 /dev/tcp

Create the tcp device using the major and minor numbers:

mknod dev/tcp c 11 42

chmod 666 dev/tcp

Repeat steps 5 and 6 for each of the following devices (each device will have a different major and minor combination):

/dev/udp
/dev/ip
/dev/kmem
/dev/kstat
/dev/ksyms
/dev/mem
/dev/null
/dev/stderr
/dev/stdin
/dev/stdout
/dev/ticotsord
/dev/zero

Set permissions on the devices in dev in the chroot directory:

chmod 666 dev/*

Create and populate lib and usr/lib in the chroot directory:

mkdir usr

mkdir usr/lib

ln -s /usr/lib

ln /usr/lib/* usr/lib

You can ignore the messages this command generates.

If the /usr/lib directory is on a different file system, replace the last command with the following:

cp -rf /usr/lib/* usr/lib

Create and populate bin and usr/bin in the chroot directory:

mkdir usr/bin

ln -s /usr/bin

ln /usr/bin/* usr/bin

You can ignore the messages this command generates.

If the /usr/bin directory is on a different file system, replace the last command with the following:

cp -rf /usr/bin/* usr/bin

Create and populate etc in the chroot directory:

mkdir etc

ln /etc/passwd /etc/group /etc/netconfig etc

Test the chroot environment:

chroot chroot bin/ls -l

The output should look something like this:

  total 14
  lrwxrwxrwx        1 root      other      8 Jan 13 03:32 bin -> /usr/bin
  drwxr-xr-x        2 user      group      512 Jan 13 03:42 cgi-bin
  drwxr-xr-x        2 root      other      512 Jan 13 03:28 dev
  drwxr-xr-x        2 user      group      512 Jan 13 03:26 docs
  drwxr-xr-x        2 root      other      512 Jan 13 03:33 etc
  lrwxrwxrwx        1 root      other      8 Jan 13 03:30 lib -> /usr/lib
  drwxr-xr-x        4 root      other      512 Jan 13 03:32 usr

You can set the virtual server’s chroot directory in one of these ways:

Use the chroot parameter of the send-cgi function in the obj.conf file. For more information, see the Sun ONE Application Server Developer’s Guide to NSAPI.
Enter this information using the Administration interface:
Open the HTTP Server component under your server instance.
Go to the Virtual Servers page.
Click on the name of the virtual server for which you are specifying CGI directories.
Click on the General tab.
Type a value in the Chroot field.
Click on the Save button.
Go to the server instance page and select the Apply Changes button.

For more information, see the Sun ONE Application Server Administrator’s Guide.

---

Adding CGI Programs to the Server

To add CGI programs to the Sun ONE Application Server, simply do one of the following:

Drop the program file in a CGI directory (if there are any).
Give it a file name that the server recognizes as a CGI program and put it in any directory at or below the document root (if CGI file type recognition has been activated).

For UNIX, make sure the program file has execute permissions set.

---

Setting the Priority of a CGI Program

To set the priority of a CGI program:

Open the HTTP Server component under your server instance in the Administration interface.
Go to the Virtual Servers page.
Click on the name of the virtual server for which you are specifying CGI directories.
Click on the General tab.
Type a value in the Nice field. This increment determines the CGI program’s priority relative to the server. Typically, the server is run with a nice value of 0 and the nice increment would be between 0 (the CGI program runs at same priority as server) and 19 (the CGI program runs at much lower priority than server). You should not increase the priority of the CGI program above that of the server.
Click on the Save button.
Go to the server instance page and select the Apply Changes button.

For more information, see the Sun ONE Application Server Administrator’s Guide.

---

The Query Handler

Note	The use of Query Handlers is outdated. Although Sun ONE Application Server and Netscape Navigator clients still support it, it is rarely used. It is much more common for people to use forms in their HTML pages to submit queries.

You can specify a default query handler CGI program. A query handler processes text sent to it via the ISINDEX tag in an HTML file.

ISINDEX is similar to a form text field in that it creates a text field in the HTML page that can accept typed input. Unlike the information in a form text field, however, the information in the ISINDEX box is immediately submitted when the user presses Return. When you specify your default query handler, you tell your server to which program to direct the input. For an in-depth discussion of the ISINDEX tag, see an HTML reference manual.

To set a query handler, perform the following steps:

Open the HTTP Server component under your server instance in the Administration interface.
Go to the Virtual Servers page.
Click on the name of the virtual server for which you are specifying a query handler.
Click on the CGI tab.
Click on the Query Handler option.
Use the Editing Picker to select the resource you want to set with a default query handler.

If you choose a directory, the query handler you specify runs only when the server receives a URL for that directory or any file in that directory.

In the Default Query Handler field, enter the full path for the CGI program you want to use as the default for the resource you chose.
Click on the OK button.
Go to the server instance page and select the Apply Changes button.

---

Perl CGI Programs

You cannot run CGIs using Perl 5.6.x with the -w flag. Instead, include the following code in the file:

use warnings;

---

Global CGI Settings

To change global CGI settings:

Open the HTTP Server component under your server instance in the Administration interface.
Go to the HTTP Server page.
Click on the Advanced tab.
Click on the CGI option.
You can change the following settings:
MinCGIStubs - Sets the number of CGIStub processes that are started by default. This value must be lower than MaxCGIStubs. The default is 2.
CGIExpirationTimeout - Specifies the maximum time in seconds that CGI processes are allowed to run before being killed. The default is 0, which means processes are allowed to run indefinitely.
CGIStubIdleTimeout - Kills any CGIStub processes that have been idle for this number of seconds. The default is 30.
MaxCGIStubs - Sets the maximum number of CGIStub processes the server can execute concurrently. The default is 10.
Click on the OK button.
Go to the server instance page and select the Apply Changes button.

For more information about these global CGI settings, see the init.conf file description in the Sun ONE Application Server Administrator’s Configuration File Reference.

---

CGI Variables

In addition to the standard CGI variables, you can use the Sun ONE Application Server CGI variables in CGI programs to access information about the client certificate if the server is running in secure mode. The CLIENT_CERT and REVOCATION variables are available only when client certificate based authentication is enabled.

The following table lists the Sun ONE Application Server CGI variables.

Table 8-1  CGI Variables 

Variable	Description
SERVER_URL	The URL of the server that the client requested
HTTP_xxx	An incoming HTTP request header, where xxx is the name of the header
HTTPS	ON if the server is in secure mode and OFF otherwise
HTTPS_KEYSIZE	The keysize of the SSL handshake (available if the server is in secure mode)
HTTPS_SECRETKEYSIZE	The keysize of the secret part of the SSL handshake (available if the server is in secure mode)
HTTPS_SESSIONID	The session ID for the connection (available if the server is in secure mode)
CLIENT_CERT	The certificate that the client provided (binary DER format)
CLIENT_CERT_SUBJECT_DN	The Distinguished Name of the subject of the client certificate
CLIENT_CERT_SUBJECT_OU	The Organization Unit of the subject of the client certificate
CLIENT_CERT_SUBJECT_O	The Organization of the subject of the client certificate
CLIENT_CERT_SUBJECT_C	The Country of the subject of the client certificate
CLIENT_CERT_SUBJECT_L	The Location of the subject of the client certificate
CLIENT_CERT_SUBJECT_ST	The State of the subject of the client certificate
CLIENT_CERT_SUBJECT_E	The E-mail of the subject of the client certificate
CLIENT_CERT_SUBJECT_UID	The UID part of the CN of the subject of the client certificate
CLIENT_CERT_ISSUER_DN	The Distinguished Name of the issuer of the client certificate
CLIENT_CERT_ISSUER_OU	The Organization Unit of the issuer of the client certificate
CLIENT_CERT_ISSUER_O	The Organization of the issuer of the client certificate
CLIENT_CERT_ISSUER_C	The Country of the issuer of the client certificate
CLIENT_CERT_ISSUER_L	The Location of the issuer of the client certificate
CLIENT_CERT_ISSUER_ST	The State of the issuer of the client certificate
CLIENT_CERT_ISSUER_E	The E-mail of the issuer of the client certificate
CLIENT_CERT_ISSUER_UID	The UID part of the CN of the issuer of the client certificate
CLIENT_CERT_VALIDITY_START	The start date of the certificate
CLIENT_CERT_VALIDITY_EXPIRES	The expiration date of the certificate
CLIENT_CERT_EXTENSION_xxx	The certificate extension, where xxx is the name of the extension
REVOCATION_METHOD	The name of the certificate revocation method if it exists
REVOCATION_STATUS	The status of certificate revocation if it exists

Previous      Contents      Index      Next

---

Copyright 2003 Sun Microsystems, Inc. All rights reserved.