You are here

The sweb service


The sweb web service is an alternative to homepages and group web space, but with better security and privacy. This page explains how to configure and use it.

sweb is like homepages except that:

  • Files are stored in (resilient, highly available) AFS rather than in (old technology) NFS space.
  • Each user's web presence runs under its own separate ID, instead of under a single shared ID.
  • sweb pages are on the web at


If the page test.html was published by user fred it would appear at
The page's source would live in AFS at /afs/

For related files that are not intended to be web-visible (README and other house-keeping files, intermediate or temporary files used by scripts, and suchlike) there is a data directory (for example, /afs/, which is a sibling of the web directory. These "data" files are only accessible via the filesystem, and not via the web.

The additional security of these pages lies in the use of a user-specific ID when the user's web pages are accessed by the web server. This prevents inadvertent damage by other users' rogue or poorly-written scripts. The user-specific ID will not normally be explicitly used by the user, other than to set access permissions.

Running scripts

CGI scripts are permitted. PHP scripts must be CGI-embedded. Scripts and other web-accessible pages should be located somewhere below the user's web sub-directory. They are run using a user-specific ID, and so are restricted by relevant ACLs.

If you wish to separate scripts from other web pages (for example, by creating a web/cgi-bin directory) then this separate scripts location (just "cgi-bin" in this illustration, not the "web/" bit) will need to be included as part of the URL (such as, or a user-specific redirect or alias set up (in a .htaccess file, for example).

The user may create a separate scripts directory with any name they prefer, but to make this separate scripts directory somewhere that does not require the .cgi extension, the SetHandler directive must be specified in the .htaccess file:

SetHandler cgi-script

Normally if a web script created a file, that file would be owned by the <apache> ID in Unix filespace. On sweb.inf, a CGI script that writes to Unix filespace (a command such as "touch /tmp/TOUCHME", for instance) gives a file owned by the user. Running the same script to write to AFS filespace uses the restricted <user>.sweb ID.

Note also that the behind-the-scenes web mechanism (suEXEC) that runs the script as the script-owner requires certain conditions to be satisfied before it will allow the script to run - so if there are run-time problems, make sure that these conditions are satisfied. They include:

  • the directory must not be writable by anyone else
  • the target CGI/SSI program must not be writable by anyone else
  • the target CGI/SSI program must not be setuid or setgid
  • the file must be owned by the username extracted from the invoking URL

Other Customisations

The user is allowed to customise the sweb environment by means of an .htaccessApache AllowOverride Directive documentation.

ACL Permissions

Files within the /afs/ structure need specific permissions if the mechanism is to work correctly. There is a system:securewebserver AFS group that will always have the server host as a member, and - if required - this group should be used when setting permissions instead of any specific host.

The <user>.sweb ID must have at least "read" & "lookup" ("rl") permission on all directories, and the <user> ID will require "write" permissions. The default permissions of the above example would be:

  Access list for /afs/ is
  Normal rights:
     system:administrators rlidwka
     fred rlidwk
     fred.sweb rl

This allows web access as the restricted user fred.sweb, but full access via the filesystem as user fred.

Last reviewed: 

System Status

Home dirs (AFS)
Other services
University services
Scheduled downtime

Choose a topic