Documentation page for Secure AFS web server

It is now possible to publish AFS-based web pages that have a greater degree of protection than the mechanism currently employed on groups.inf or homepages.inf.

A new server, sweb.inf, provides AFS space that is accessible anywhere (as normal) and is editable by the user (also as normal), but the web access via apache is constrained to a separate, user-specific ID (not the generic <apache> ID as is normal on other web servers). This access ID is not usually visible to, or used by, the user (although it is accessible if required). The resulting filespace should benefit from the resilience and availability of AFS, and be better-protected from any server-side issues (such as another user's mis-configured script).

This page describes how to properly configure and use this filespace.


The URL of the more-secure web server is, and user pages sit below the user ID at that site, so that the "test.html" page of user "fred" would be (note the use of the tilde, "~").

The corresponding filespace is within the AFS file-structure, and accessible in the "web" sub-directory below the user directory in /afs/ (thus the path corresponding to the URL above would be /afs/

The additional security of these pages lies in the use of a user-specific ID when the user web pages are accessed by the web server behind the scenes. This prevents inadvertent damage by rogue or poorly-written scripts (as may happen on other websites that use a generic ID to access pages). The user-specific ID will not normally be explicitly used by the user.

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, not via the web.

Running scripts

CGI scripts are permitted, although PHP ones are not (unless CGI-embedded). Currently scripts (as well as other web-accessible pages) must be located below the user's web sub-directory, and these scripts are run using the user-specific ID, so are restricted by relevant ACLs. If you wish to separate scripts from other web pages (by creating a web/cgi-bin directory, for example) then the separate 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).

Note that, if a script writes a file, that file would normally be owned by the <apache> ID in Unix filespace. On sweb.inf, a CGI script writing to Unix filespace (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>.web ID.

ACL Permissions

Files within the /afs/ structure need specific permissions if the mechanism is to work correctly. The web server has its own host-specific ID, and this must have at least "lookup" ("l") permission on all directories. The user will (presumably) require "write" permissions, and the restricted user-specific web ID (of the form sweb.fred) will need "read" permission. The default permissions of the above example would be:

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

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

Note that the AFS secure web server ID (currently will also need rl ACL permissions on any directory from which files will be served and l ACL permission on all parent directories (as is the case in the example above). However, there is a system:securewebserver AFS group that will always have the server host as a member, and this group should be used instead of the specific host. For example:

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

Note also that the behind-the-scenes 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

-- RogerBurroughes - 25 Mar 2015

Topic revision: r10 - 09 Apr 2015 - 11:49:31 - RogerBurroughes
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies