View on GitHub

CGI and PHP scripts


On the SRCF’s webserver, you can run CGI and PHP scripts! What’s more, we have a brilliant system in operation which allows even your PHP scripts to run as ‘you’ rather than as the webserver. Read on for details.

Location of your CGI files

For personal users, PHP scripts must have a filename ending with ‘.php’ and can be placed anywhere in your public_html directory. CGI scripts must have filenames ending ‘.cgi’ and can also go anywhere in public_html.

For group accounts, both of the above methods also work, however there is an additional method of running CGI scripts which is to place them in the cgi-bin directory in your group account user area (i.e. not in public_html). If you do this, the script names do not need to end ‘.cgi’. The URL to access CGI scripts in the cgi-bin directory is https://<groupname>, where <groupname> is the group account name.


For personal users, both PHP and CGI scripts will run as you, not as the web server’s user id.

For group accounts, rather than running CGI/PHP scripts as an individual, we have introduced a UNIX user for each group account. This user cannot log in, however it is used as the user under which all group account PHP/CGI scripts are run. Outgoing email generated by group account CGI/PHP scripts will, by default, appear to come from <groupname> See Group email addresses.

Note that any CGI/PHP script which hogs the CPU for more than 2 minutes will be terminated by the system. This should not affect anything other than out-of-control scripts, as CGI/PHP scripts typically execute in a few seconds. It is a measure to prevent the server being excessively slowed down by buggy scripts which go into an infinite loop.


For personal users, CGI scripts must be readable and executable by you, and must be owned by you. PHP scripts must be world-readable (but to keep database passwords secret, see the next question). For example:

spqr2@pip$ ls -l
-rwx------  1 saw27  saw27  238 May  5 19:33 env.cgi
-rw-r--r--  1 saw27  saw27  265 May 13 19:34 phptest.php

CGI scripts and PHP scripts belonging to a group account must have their system (UNIX) group owner set to that of the group account. CGI scripts must be system group readable and executable. Group account PHP scripts must additionally be world readable (but to keep database passwords secret, see the next question). For example:

spqr2@pip$ ls -l
-rwxrwx--- 1 saw27  casi  238 May  7 23:49 env.cgi
-rw-rw-r-- 1 saw27  casi  265 May 14 23:06 phptest.php

We recommend that you ensure that group account files are group-writable, so that other admins of the group account can edit them (not least, when your own personal account expires).

Managing secrets

PHP scripts must be world-readable. This requirement is artificially imposed because we felt that if we didn’t require world readability, users might be caught out by assuming that if something (other than a CGI script) is not world readable then it’s not accessible on the web, which wouldn’t be the case for PHP scripts. But it’s easy to get round: put your secret information in a separate file which is not world readable (but is system group readable), and include that file from your main PHP script.

Managing memory

By default we have a maximum memory limit of 64MB set for PHP scripts. You can override this by placing a file called php_override.ini at the top level of your site containing, for example, memory_limit = 128M.

Please consider the memory requirement of other users, system processes, etc. before doing this.

Turn CGI off

Several kinds of file will automatically be interpreted as CGI scripts, and so the CGI handler will try to run them when you visit their URL, even if you just wanted to download them. The following will turn off CGI handling for Python scripts, displaying them as plain text instead:

AddHandler default-handler .py
AddType text/plain .py

Put those lines in a .htaccess file in the same directory as your python files, and they will no longer be considered CGI scripts. You can do a similar thing for other file types by changing the .py to, for example, .php.

Last modified on Monday Feb 28, 2022 by Richard Allitt