[OpenAFS] AFS && Apache

Todd M. Lewis Todd_Lewis@unc.edu
Thu, 16 May 2002 09:35:32 -0400


Charles Clancy wrote:
> 
> Anyway, personal web pages that use any sort of scripting to write data to
> home directories is something I never had a real good solution to.

Time will tell how good our solution is, but here's how we're
implementing general user level CGI support for our AFS users.

First, if a user wants to have CGI scripts, she has to go to our service
subscription page and subscribe to the service.  This subscription
process creates a CGI instance of her principal ('janedoe.cgi'),
generates a password which she'll never see, creates a
~janedoe/public_cgi directory and gives janedoe.cgi read access to it,
and records her principal, instance, instance password, and path to her
public_cgi directory into a file that can only be read by webgod.cgi. 
Think of this file sort of like a shadow /etc/passwd file for CGI users.

Our httpd.conf defines a "ScriptAlias /usr-bin/ /path/to/cgimagic/".
cgimagic is an suid-root program that can read a root-only accessible
file that contains webgod.cgi's key and a list of runlimits.  cgimagic
sets a PAG, gets a webgod.cgi token (which is good for nothing at all
except reading the file mentioned in the previous paragraph), figures
out from the PATH_INFO and other environment variables that
http://www.somplace.net/usr-bin/janedoe/sub/xyz.pl is supposed to run
janedoe's sub/xyz.pl script, looks up jonedoe.cgi's particulars
(instance password and public_cgi path), re-authenticates as
janedoe.cgi, manipulates the PATH_INFO, SCRIPT_FILENAME, and SCRIPT_NAME
env vars so that her script won't know that it wasn't called directly,
sets umask to 0177, sets the runlimits we read in with webgod.cgi's
password, setuid() to janedoe.cgi's PTS id #, and finally execs her
script.  cgimagic looks for any excuse it can not to run her script and
dies with a vaguely helpful message to the browser if it finds anything
it doesn't like.

If jane needs to write to someplace in AFS, she can set a write ACL on
some directory for janedoe.cgi without compromising other areas.  If she
writes in /tmp or some other local file system, she's running as her PTS
id#, so her scripts can't compromise others and vice versa (assuming
reasonable coding practices of course).  And she'll only be able to read
things any authenticated user can read, plus those directories to which
janedoe.cgi has been given explicit read access.

How well this scales is yet to be seen; we've only done some preliminary
testing so far.  It has to set a PAG, authenticate twice, and exec; I
don't have much of a feel for how expensive these operations are.  I
know people are not comfortable running suid-root programs under web
servers, and it involves an AFS file of hidden keys and another local
file with the key to that AFS file... Still, it's the safest environment
I'm aware of for providing general CGI access to AFS users on
centralized web servers.
-- 
   +----------------------------------------------------------------+
  / Todd_Lewis@unc.edu                  http://www.unc.edu/~utoddl /
 /(919) 962-5273  Linux - It's now safe to turn on your computer. /
+----------------------------------------------------------------+