When the web server gets a request for an URL such as
http://bayle.stanford.edu/cgi-bin/cgiwrap/spw/spw.pl
, cgiwrap is invoked. Cgiwrap chroots to the spw filesystem, changes user to the spw user, and then runs the perl script /var/www/spw.pl, which is owned by root. You can follow along with what Cgiwrap is doing by using "cgiwrapd" in an URL instead of "cgiwrap", for instance:
http://bayle.stanford.edu/cgi-bin/cgiwrapd/spw/spw.pl
/var/www/spw.pl sets up a Safe compartment as described on the PerlSafe page. /var/www/UsemodUnsafeInit.pl is run within the compartment, but unrestricted; this file does things like load Perl Modules which require more privileges than we want to give to the Safe compartment.
The Safe compartment is then restricted to only use certain opcodes in the future, as described in PerlSafe. The Safe comparment is also given access to a number of functions in /var/www/UsemodUnsafe.pm (as described in PerlSafe). /var/www/UsemodUnsafe.pm uses the config file /var/www/unsafeConfig. Some weird stuff is done that I don't understand (and I wrote it!) but which I think forces the autoloading of certain CGI.pm modules while we have enough privileges to do so.
Next, /spw/wikidb/config is executed within the restricted Safe compartment. This is done at this point because there currently is no way for a script in the restricted compartment itself to execute the equivalent of an "eval" or "do" command.
Now, /spw/spw_main.pl is executed within the restricted Safe compartment.
This file is just UseMod, but with disallowed operations replaced by the appropriate calls to UsemodUnsafe.pm. Everything under the /spw directory is owned by the spw user, so /spw/spw_main.pl can modify any data or other scripts in that directory (unfortunately it does not yet have a working mechanism to call another script within the Safe compartment, a critical need -- but it's coming).