The contrib webserver serves content from the directory named www in your andrew account's home directory in AFS. By default, this directory is writable only by you and readable by anyone (including the contrib webserver). We have developed a way to allow CGI scripts on the contrib webserver to write to portions of this directory or read particular files that you are otherwise preventing access to. This is done by having your CGI scripts run authenticated as a special user which you may add to AFS access control lists (ACLs).

Before you go any further, you must access the My Contrib interface and activate authenticated AFS support. This creates a special user called contrib.[your andrewid]@club.cc.cmu.edu which you can then add to ACLs on your www directory and any subdirectories.

Quick summary:

• To allow CGIs on the contrib webserver to write to the files in a particular directory, type:
  cd [that directory]
  fs sa . contrib.[your andrewid]@club.cc.cmu.edu rlidwk
• To prevent anyone except CGIs on the contrib webserver from reading the files in a particular directory, type:
  cd [that directory]
  fs sa . system:anyuser none
  fs sa . contrib.[your andrewid]@club.cc.cmu.edu rl

For more complete information, see the computing services AFS documentation or the AFS user's guide chapter on directory and file protection.

The ability for CGIs on the contributed webserver to access AFS with authentication allows for a number of unique abilities that would otherwise be impossible. For instance:

• Many CGI scripts that make use of SQL databases need to store your SQL database password in the script or a special configuration file. Naturally, you want to keep this password secret, and it would not be if it were in a world-readable directory. You can secure this password by setting an ACL on the directory containing this file to prevent read access to system:anyuser and enabling read access for your special contrib user (contrib.[your andrewid]@club.cc.cmu.edu). Note, however, the limitation (described further below) that you cannot protect the CGI (or its containing directory) itself.
• Many CGI scripts need to write to a data directory, perhaps to store temporary files, image thumbnails, or any other data storage need that doesn't make use of an SQL database. You don't want to create a world-writable directory (lest a malicious user fill your volume or corrupt your program's data), so you can enable write access for your special contrib user (contrib.[your andrewid]@club.cc.cmu.edu).
• You may use a CGI script to selectively serve restricted content stored in a protected directory that is inaccessible to the world but which can be read by the script.

This is implemented on our CGI server through special patches to the suexec CGI wrapper for apache that acquire kerberos tickets (and then AFS tokens) for the principal contrib.[your andrewid]@club.cc.cmu.edu just prior to executing your CGI. This authentication context (technically, a PAG) is inherited by any other programs your CGI may spawn but is not shared by other instances of the same CGI spawned by different webserver requests.

Limitations

• Authenticated AFS access is only implemented for CGI scripts, not static content. For efficiency, this is unlikely to change. This means that you still cannot set protective AFS ACLs on a directory and have non-CGI content thereunder served only by the contrib webserver (which, for instance, you might want further protect with WebISO authentication). Instead, you might use a CGI script to act as a proxy to this content by having it authenticate incoming requests, read the content from the protected AFS directory, and return it to the user.
• Because incoming requests are screened by our front-end webservers (which do not use AFS authentication) to sort out CGI requests for execution, you cannot protect the directory containing the CGI itself. If, for instance, you want to protect a database password stored in a script, you must place the password in a file in a separate protected directory and have the script load this file. Likewise, if you want to protect the source to your script from public viewing, you can have the main CGI executed by the contrib webserver just be a little script that loads or runs the actual CGI located in a protected directory.
• Be careful when making use of both this service and the official andrew web publishing service. You might break andrew web publishing by having protected directories (e.g., directories the andrew webserver can't access), and you might break directory protection by using andrew web publishing (e.g., by serving to the world content you intended to protect).