You are here
The sweb service
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 https://sweb.inf.ed.ac.uk.
If the page
test.html was published by user fred it would appear at
The page's source would live in AFS at
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/inf.ed.ac.uk/web/securepages/fred/data), 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.
CGI scripts are permitted. PHP scripts must be CGI-embedded. Scripts and other web-accessible pages must currently be located below the user's
web sub-directory. They are run using a 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 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
https://sweb.inf.ed.ac.uk/fred/cgi-bin/myscript.cgi), or a user-specific redirect or alias set up (in a
.htaccess file, for example).
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
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
Files within the
/afs/inf.ed.ac.uk/web/securepages 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 this group should be used when setting permissions instead of any specific host.
This server ID 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/inf.ed.ac.uk/web/securepages/fred is
This allows web access as the restricted user
sweb.fred, but full access via the filesystem as user