Informatics homepages web service

Most Informatics staff and research related postgraduate students can publish personal web pages on the homepages.inf service. Most are also allowed CGI script access. Users are responsible for anything that they publish, and they are bound by the Computing Regulations.

If you have permission for either of these, you will find these directories on DICE computers:

    /public/homepages/username/web
  

and

    /public/homepages/username/cgi
  

... where username is your DICE username. For the rest of this document we will take user 'fred' as an example of username.

The disk space in /public/homepages/ is subject to a disk quota - currently 20MB for research students and 50MB for staff. Requests for more space should be sent to computing support.

The basics

The web server is running Apache 2.4. It has been slightly tweaked, mainly for the user CGI feature.

The file /public/homepages/fred/web/index.html will be visible on the web as the URL https://homepages.inf.ed.ac.uk/fred/index.html.

Similarly the CGI program /public/homepages/fred/cgi/myscript will be accessible as https://homepages.inf.ed.ac.uk/cgi/fred/myscript.

Anything in /public should be considered public. Page access can be restricted (using .htaccess files and file permissions) but misconfiguration or a faulty CGI script can render these restrictions meaningless.

You also have to consider that for the apache server to be able to serve your pages to the outside world, it must be able to read them. This means that their traditional unix file permissions need to be either: owned by the "apache" user, group readable by "apache", or other(world) readable. The DICE default umask will mean this is not the case by default.

Currently the apache server supports Server Side Includes (mod_include) and PHP 8.1. Files ending in .shtml and .html are parsed with mod_include, and files ending in .phtml and .php are parsed as PHP.

The people pages under https://www.inf.ed.ac.uk/people/ are automatically generated from data held in the school database. If you wish to have a 'Personal Page' link to your homepages appear beside your telephone and room number details on your contact page then please use the Webmark self service form.

More detail

One important thing to note is that - for security reasons - it is recommended that you do not try have have the homepages web server access files outside of your /public area. Indeed, the /home path has been deliberately disabled for this reason.

Another important change from SL7 to Ubuntu Jammy, the SCRIPT_NAME header has changed, and we reccomend you change uses of it to be HTTP_SCRIPT_NAME

CGIs

• The homepages web server runs with mostly the same set of software packages that you'd find on a standard Ubuntu DICE desktop, although an exact match of software and versions is not guaranteed.
• Your CGI scripts will run as your userid. In theory they have read/write/delete access to any of the files that you own. If you write and install a script that can be exploited, then potentially a malicious user could delete all your files. However it does not obtain your AFS credentials, so by default any AFS space should be safe.
• As your networked home directory (e.g. /home/fred/) is not available to the web server, you cannot write scripts that take some form of input and write data back to your /home/ home directory, only your /public/homepages/fred/{web,cgi,data}/ directories.
• CGIs need to be executable, and be owned by your user ID, or the server will not run them.
• CGIs will not be executed if they are somehow modifiable by other people, e.g. they are within a group/world-writable directory, or the CGI itself is world/group-writable.
• You do not have access to the apache logs. If you have problems with your CGI and it produces errors, you cannot access the apache logs to see any output it may have produced. The usual trick to debug CGI problems is to run the CGI from the command line (cd to your CGI area and do ./scriptname) and make sure it produces the correct header and output on the standard output. For example:
  

      Content-type: text/html
    
      <html>
      ...
      </html>
    

  Note the blank line between the Content-type line and the first HTML tag.

• If your CGI is written in perl, then the following may be useful to aid debugging:
  

      #!/usr/bin/perl
    
      use CGI::Carp qw(fatalsToBrowser set_message);
    
      BEGIN {
           sub handle_errors {
               my $msg = shift;
               print '<h1>An error occurred</h1>';
               print '<p>The following error occurred in your CGI:';
               print '<pre>'.$msg.'</pre>';
           }
           set_message( \&handle_errors );
      }
    

PHP

• PHP is run as a CGI. This means any PHP scripts have the same local file level access as the owner of the file (but not AFS files, as they do not get the necessary AFS credentials). Because of this, PHP scripts will not be executed if they are somehow modifiable by someone else, eg if they are group or world writeable, or if the directory they are contained within are group or world writeable.

  The base PHP on a DICE Ubuntu machine is 8.1 and the binary is located at /usr/bin/php.

• As for CGIs above, your home directory (e.g. /home/fred/) is not available for input or output to PHP scripts.
• If you want .html files to be parsed by PHP, then you need to add the following line to a .htaccess file (you may need to create this file) in your homepages area:
  

      AddHandler php8.1-script .html 
    

• The following lines at the beginning of your PHP may help you debug problems:
  

      <?php
        ini_set("error_reporting", E_ALL);
        ini_set("display_errors", TRUE);
      ?>
    

SSIs

• Your personal web pages have the apache directive:
  

   Options IncludesNOEXEC
    

  So you will not be able to execute scripts or commands from SSI.

Accessing Postgres - pgteach.inf and pgresearch.inf

• The postgresql topic explains lots about the access mechanisms to pgteach.inf and pgresearch.inf. The databases prefer SSL kerberised connections. If you try to use this in your CGI, it will be unable to connect to your DB. You need to fallback to using plain username and password authentication over a non-SSL connection. See the above link on how to obtain a plain password, and then use something like the following to force a non-SSL connection, for example in PHP:
  

      <?php
        $dbconn = pg_connect ("host=$server dbname=$db user=$username password=$password sslmode=disable")
      ?>
    

  Other languages should have a similar way of forcing a non-SSL connection.

Security

Though correctly configured authentication and authorisation will work and limit access to wherever it has been configured for, because homepages is a multi-user service, you also have to trust the rest of the users of the service. If you do not trust all Informatics users, then you can't guarantee if someone authenticates as FRED on to a restricted part of your homepages, that they are indeed FRED. That's not to say that FRED is the bad guy, but rather someone else, JACK (for example) has (as a fellow user of homepages) been able to get FRED to to authenticate to one of JACK's pages. Using that information JACK is then able to impersonate FRED when connecting to another restricted part of homepages. There are other ways JACK could also obtain FREDs identity while using homepages.

Similarly anyone authenticating to any website/service, is trusting that the person running that website is not doing anything they shouldn't be with the information provided. The difference here with homepages, is that you are trusting the individual authors of the pages.

Obviously all users of the University systems are bound by the computing regulations, and anyone trying to access systems as another person are committing a crime (Computer Misuse Act).

Problems

Try the general web FAQ. Any technical problems with the homepages service should be reported via the Support form.