The version of PHP installed on the departmental webserver is a stable and secure version. Most common PHP libraries should already be installed. If there is one you need that isn't installed and you can find it in the standard Ubuntu repositories contact us via our (non-ICT) Helpdesk system and we can install it for you.

We use Suexec and CGI for running PHP scripts rather than mod_php. This provides a more secure environment but means that downloaded PHP applications may not work out of the box, because most people designing PHP scripts assume that mod_php will be used. However, we view this as an excellent security precaution, as it means that you can't just download a PHP app and install it and let it run without having to think about how to make it run!

The most obvious consequence is that all PHP scripts must start with the line "#!/usr/bin/php" and be executable.

The most common problem users have with pre-written PHP software is that an existing tree of PHP source files will not have #!/usr/bin/php at the beginning of the scripts, and, worse still, PHP makes no distinction between a program (script invoked by a URL) - which needs #!/usr/bin/php adding - and a library (file which is included into another PHP file) - which does not need, and must not have, the #!/usr/bin/php line added. So, in this situation, you need to identify which individual PHP files are programs (scripts, accessed as URLs) and add the #!/usr/bin/php to just those files.

Note that if you download PHP scripts from the Internet, you are responsible for ensuring that the scripts really do what they say they will, do not misbehave and are secure. Bear in mind that by allowing these scripts to run as CGI scripts on our web servers, they will be invoked by untrusted users across the Internet, but will run with your user privileges on our web server, and hence have the same access to files in your home directory as you do!

If you choose to use a well known piece of web software (eg a wiki or a content management system), it is quite likely that particular versions of such software will have vulnerabilities which hackers know how to exploit via web attacks. It isyour responsibility for keeping your web-based software up to date and (as far as possible) secure. If you get our webserver hacked because you have not kept your chosen software up to date, we will be extremely annoyed with you. As Terry Pratchett so nearly says:

  • Do not meddle with the affairs of systems programmers [wizards]. They're not all that subtle, and quick to anger.

Our webservers (www.doc.ic.ac.uk and www-homes.doc.ic.ac.uk) currently run Ubuntu 18.04 (aka Bionic Beaver), and will be updated to the latest stable release 20.04 (Focal Fossa) in due course.

AN EXAMPLE

Here is an example of a basic PHP script that resides in the root of a users public home directory:

$ cd ~/public_html

$ ls -lad /homes/help/public_html
drwxr-xr-x   20 fred    csg          8192 Feb  1 14:10 ./

$ ls -la test.cgi
-rwx------    1 fred    csg            44 Feb  1 13:45 test.cgi

$ cat test.cgi
#!/usr/bin/php
<?php
echo "hello world";
?>

Key points to note:

  • The script has to be executable. To ensure a script is executable run chmod +x <filename> 

  • The script is only writable by the owner of the file. If other users can write to the file then Apache's suexec mechanism will refuse to execute it. To ensure that this is the case run  chmod 755 <filename>

  • The only exception are scripts in group project directories which can be group writable. To ensure that this is the case run  chmod 775 <filename>

  • The file must be in "Unix format" [Unix line endings, ie. each line ends in a newline character only]. Windows and MacOS line endings will not work. If you created or edited the file on Windows run  dos2unix <filename>  to convert it to "Unix format".

  • If you get an "Internal Server Error" with a script check the log in /vol/wwwhomeslogs/suexec.log

GROUP PROJECT AREAS

A few things to note about permissions if you are running scripts from a group project areas (ie. somewhere in /vol/project/...).

  • everything should be group readable, writable, and executable (if necessary).  chmod 775 <filename> 

  • all new directories created should have chmod g+s done on them to cause newly created files and directories inside them to inherit the parent directory group (eg. g1136204) rather than using the creating user's primary group (eg. jmc3).  chmod g+s <directory>

Useful contacts

  • News
  • Events

News and events

Click here to discover what we've been up to and how you can get involved.