Development Project 301: Secure Web Server


This project was intended to provide a new, secure web server with AFS-mounted file-space where users could store secure, sensitive data.

Work Done

Installed VM to host service (with 8Gb for /var/cache/afs), configured X509, Apache and CoSign. Created an AFS principal for, and the associated AFS filespace for /afs/ (note that users' space needs to be readable by

Created sweb principals for test users, and experimented with access constraints. Also created the system:securewebserver group, to avoid explicit reference to web server host name.

Configured script location to be /afs/*/cgi-bin, and allowed user access by restricted ID <user>.sweb. Considered updating suexec code to allow access to script location, but managed to avoid this by rebuilding httpd RPM (which includes suexec) using specfile definition to modify suexec rather than changing code explicitly. Also had to enable localhome for user directories, which is required to trigger use of UserDir which, in turn, invokes suexec.

Updated the front page to reflect the same styling as homepages.inf, and added another RewriteCond[ition] to the configuration to allow for exclusions to the otherwise universal tilde additions.

User and Support documentation is available at:


The main problem was access by Apache, the primary technical consideration is that apache needs to be able to authenticate against our KDC, needs to be able to obtain AFS tokens for the principal it's authenticated as, and AFS acls need to be configured accordingly to provide access to the underlying files.

Secure-web document URLs can be of the form:

Although, as mentioned above, suexec needs to be triggered for a script in order to invoke the correct Apache access, which is done by the inclusion of a tilde. This tilde can be explicit or implicit: or

- if not present, a tilde is added by Apache prior to filtering through suEXEC. It is assumed that the tilde-less form will be the default.

Although the implemented mechanism works, based on allocation of specific and distinct AFS IDs, this approach will not necessarily scale if there are not sufficient AFS IDs available for assignment to all users. A more robust and scaleable solution needs to be investigated.

Toby has pointed out that:

"[there is] code in gerrit which automates the assigning of uid numbers when creating additional identities for a user, e.g. username/something. However, it needs to be configured with the uid ranges that are available, so getting a list of number ranges we can use still remains a potential issue."

Also, Apache uses the value of UserDir to locate the script/executable (so that finds arachne:/home/user/cgi-bin/creds.cgi), but that if the URL contains a tilde and suexec is triggered, then it uses its own expansion mechanism based on the suexec_userdir_subdir and --with-suexec-userdir compile-time settings. So, to avoid confusion, it's probably best if these match.

The service as configured operates using the service name sweb.inf, but the intention is that groups.inf may also use this mechanism at some point - in which case, we can proxy sweb from groups.inf so that people who want to use sweb can still do so under the groups.inf URL, thus hiding - and ultimately deprecating - sweb.inf. It would be better to use a Reverse Proxy rather than a Forward Proxy, since the latter merely forwards the request (and the client has to make an explicit request to forward to a particular server), whilst Reverse Proxying is completely transparent to the client. This redirection will not be done immediately, but in order to test the procedure, a proxy for was configured, pages below this location were served from sweb.inf, but appeared to still come from groups.inf.


After initial configuration, considerable time was spent checking and testing various aspects amounting, in total, amounting to 225 hours (32 days).


The required functionality is available, but there are areas where it could be tidied up or improved (the automation and expansion of AFS ID allocation being one such). The mechanism seems to work as advertised, but there have been one or two "workaround" solutions to interim problems, which is not ideal (such as the use of home-directories on arachne linked to /afs/ to effect script execution via suexec).

Peer Review

At the last sign-off submission, it was agreed that a peer-review of the web configuration should be carried out. This was done, and the following points were addressed:

  • Check permissions of waklog afsweb perms on /etc/afsweb.keytab - can it just be root:root?
    [ Yes, set ownership to root.root and mode to 600 ]
  • Similarily SSL KeyFiles: ideally not readable by apache user.
    [ Set ownership to root.root and mode to 400 ]
  • RewriteLogLevel 6 is high for a production service.
    [ Disabled ]
  • Is /test location in conf.d/waklogusertokens.conf still needed?
    [ No, removed ]
  • Having AllowOverride All in conf.d/cgibin.conf isn't how it's done on homepages.inf or groups.inf (by default)
    [ (Slightly) restricted for user home pages, as per homepages.inf ]
  • Default top-level is " Allow from All", this is not recommended.
    [ Set to "Deny All", with specific Allows further down the tree ]


Everything seems to be working as required from the user's perspective, although (as mentioned above) the configuration on the system side is not as seamless as it could be (partly due to Directive [in]compatibility). Currently configured for Apache 2.2 under SL6.6, although there may be slight tweaks that could be made under 2.4. Further enhancements or improvements could be made as operational upgrades on the live system.

-- RogerBurroughes - 01 Mar 2016

Topic revision: r12 - 02 Mar 2016 - 09:39:50 - 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