CSE's CGI Server

CSE operates a webservice where you host your own website. The URL will be: https://cgi.cse.unsw.edu.au/~username/

The files for the website will be in your CSE home directory at: ~/public_html/

The webservice will serve static webpages and files from this directory if the file permission is set o+r. It will return the output of CGI programs in that directory. CGI programs in your ~/public_html/ directory will run as your account.

Home directory mounting

Only your ~/public_html/ directory is accessible on the CGI server. Web programs do not have access to the rest of your home directory.

The Autofs mounter is configured to only mount the ~/public_html directory from user accounts in the normal home directory path. But not the whole homedir.

On the server the suEXEC module, which runs CGI programs, only runs those it can find at the correct user home directory path, within: ~/public_html/

Configuration and Access Control for Apache

The webserver software for the CGI server is Apache version 2.4.

This means you use Apache directives in .htaccess files to control your website. If you do not know what .htaccess files are, you should read the Apache guide about them.

Basic Access Control: Require

You add basic access control directives to a .htaccess file in the directory where you want those directives to apply.

Examples: Require all denied Require all granted Require ip 129.94.242.19

The Require directive comes from mod_authz_core. The mod_authz_host module enhances that with "Require ip ..." and "Require host ..." access tests.

Order, Allow, Deny

The Order, Allow and Deny directives were in the module mod_access. They were frequently used at CSE. They are deprecated syntax on the current server.

The mod_access_compat module is on the current server. It allows use of the Order directive, but it is confusing to use it along with the newer Require directive and doing so is not recommended.

Authentication

The server uses mod_authn_sasl for authentication (checking user passwords).

These directives in a .htaccess file will require users to login, with their CSE accounts before they can see directory contents. AuthName "CSE Users" AuthType Basic Require valid-user

Authorisation

Authorisation (limiting access to certain groups) uses a custom module that is a wrapper for the innetgr function. In .htaccess files you would use it like this:

HTTPS only

Content is only served over HTTPS by the server. Requests on unencrypted HTTP are all redirected to HTTPS.

Web queries will only be processed with mod_ssl enabled.

If you want to be extra sure queries only use HTTPS, use this directive in your .htaccess files: SSLRequireSSL

suEXEC runs your CGI Programs

Apache's standard suEXEC module is used to run user CGI programs on the server.

Files processed by the cgi-script content handler will be run using the account matching the home directory. In other words, your CGI scripts in your web directory will be run using your account.

To make a suEXEC CGI programs work:

• Associate the program file with the cgi-script handler in your .htaccess file. Example: <Files "thing.sh"> SetHandler cgi-script </Files> If you do not, the default-handler will likely process the file and return the contents of the file to the requester.
• File is owned by the account that will run it, and is not writable by another account. — Otherwise suEXEC will not run it and the webserver will instead return a 500 Error.
• Be executable by the account that will run them. (chmod u+rx thing.sh) Otherwise, suEXEC declines to run the script and the webserver returns a 500 Error.
• suEXEC will not run symbolic links as CGI. And so these will return a 500 Error.

• File not group-writeable nor in a directory that is group-writeable — or the webserver returns a 500 Error.
  … Possibly an overly cautious requirement, but that is how suEXEC is compiled — see point 14 in this reference.

We recommend that any file you want to run as CGI be set with restricted permissions. Eg: chmod 500 thing.cgi

cgi-bin Subdirectory

All of ~/public_html/cgi-bin/ is set to use the cgi-script handler.

This includes directories, meaning that the directory index handler is not used and directory index pages are not returned by the server. — This may be a good thing.

Files which do not have the execute bit set will return a "Internal Server Error".

Outside cgi-bin

Outside your cgi-bin/ the webserver runs files as CGI if the filename ends with : .php .cgi (but not: .pl .py .sh)
All such files must have their execute permission set, or the new server will return an error page instead of running them. Other files, by default, do not run as CGI, but are served as-is to the client.

See below for instructions on making your other files run as CGI.

Stopping a file from being CGI

The server associates file extensions directly with the web server handler cgi-script rather than through a media type. To make the server not treat files as CGI, you remove the association with the cgi-script handler: RemoveHandler .cgi

PHP

Any file within ~/public_html with the extension .php and the execute-bit set (chmod u+x) is processed by the cgi-script handler and the php-cgi interpreter.

This is due to a setting for binfmt on the server which specifies /usr/bin/php-cgi as the interpreter for .php files. (Similar to the way #! at the start of a script specifies the interpreter for that script.)

Files with the extension .phps are currently set: Require all denied

Server-Side Includes

The CGI servers allow Server-Side Includes or HTML documents that the webserver inserts content into as it sends it to a client.

Simple webpage generation is possible with this without requiring more involved CGI scripting.

The server additionally allows use of the exec element, which can run scripts as the owning user account to generate content within a webpage.

Logs of your Website

Notes/Reference

Server Configuration