Security details
The Stanford CGI Service is designed to allow execution of CGI programs while maintaining a level of security that protects other users' data from malicious or buggy programs, prevents CGI programs from unauthorized access to files and restricts access to system and network resources. The service consists of the CGI server machines, each running a Webauth webserver that executes users' programs in a secure contained environment, subsequently described.
The CGI servers execute the CGI programs within the suexec environment, which is part of the Apache webserver distribution. The suexec program has been modified to work with the Stanford infrastructure, particularly Kerberos and AFS. Suexec runs the CGI programs under the owner's user ID, and using the AFS identity of the owner's cgi principal. This restricts the program's AFS access to only those directories where AFS acls have been set accordingly. Suexec performs checks to see that the CGI program resides in a directory that has correct AFS acls, that the program is not "setuid" (can't change user IDs at will), its UNIX permissions are correct, and its process priority level, CPU, disk, memory and process usage will not exceed established resource limits.
Your CGI program will run under chroot, which creates a separate "virtual" file system that your program sees. As a result you can't access certain local files, for example if you open /etc/passwd to get a listing of all users on the cgi machine, what you will see will not actually be the password file, but a version of it under chroot. Same if you need additional system libraries — they may not be available.
There are max resource limits established for CGI programs:
| CPU Time | 60 sec |
| In memory data | 100Mb |
| Stack size | 4Mb |
| No core dumps | |
| Resident set memory | 4Mb |
| Number of processes spawned | 32 |
| File descriptors | 32 |
| Maximum file size | 50Mb |
We may raise these limits depending on usage.
Webauth - protecting CGI programs
To restrict access to their CGI programs, users can leverage the Webauth functionality of the CGI server, much in the same way as protecting their webpages in their WWW directory. The users can place a .htaccess file in their cgi-bin and in that file specify the AuthType as "WebAuth" along with any desired restrictions, as per normal WebAuth usage. For example, to simply restrict access to anyone with a valid sunetid for all the CGI programs in a directory, place this in your .htaccess file:
AuthType WebAuth require valid-user
Restricting access to CGI programs using WebAuth does not change the URL for accessing them (though the http:// prefix will be changed to https:// to enforce SSL encryption). When the CGI programs execute, they will have access to the environment variables set by WebAuth, identifying the authenticated user accessing the program; such as WEBAUTH_USER, containing the sunetid.
