Nathan:

	I just thought I would drop you a note, saying that I absolutely
	adore cgiwrap.

	Prior to now, I had been using Apache suexec. To be blunt, suexec
	is a disgusting piece of crap. The security guidelines/rules set
	forth by suexec must've been created off the top of Dean Gaudet's
	head -- half of them are absurd, and the other half don't work
	for the method of VirtualHosting I am doing. I literally had to
	re-code parts of suexec to get it to work under my server config-
	uration.

	...until I encountered cgiwrap.

	Your product works flawlessly, and fits my every need. It's
	extraordinarily fast, and it's simplicity makes it an awesome
	pre-requisite for any webmaster who wishes to run scripts in
	a secure environment.

	The best part about cgiwrap is it's (simplistic, yet useful)
	ability to redirect stderr to stdout. With so many CGI scripts
	available, and so many written in different environments, it's
	about time something came along which could make the debugging
	process as simple as cake.

	Thank you for cgiwrap.

-- 
| Jeremy Chadwick                                 System Administrator |
| yoshi@parodius.com                                      ICQ #6279222 |
|           "Where is fancy bread? In the heart, or in the head?" - WW |

It is inherently impossible to provide _total_ protection, but there
is a nifty little utility called cgiwrap that can help.  Check out
the URL:

http://www.unixtools.org/cgiwrap/

This method has several advantages:

   1. It runs the cgi script as your userid, not as some server-defined
      userid.  Assuming you are an ordinary user, this reduces the risk
      of damaging the system, while increasing the risk of mucking-up
      your own files.  That tradeoff is precisely what many admins
      on big sites want; it shifts the risk from a badly-written
      script onto its author, rather than the sysadmin.  Also, the
      fact that it runs as you means that if you do something dumb
      or nasty with it, the administrators have a better chance of
      determining who is responsible.

      Also, this means that if a cgi script hangs and fails to die, you
      can kill it yourself; if it runs as some special userid then only
      the system administrator can kill it should it run amuck.

   2. It does some security checking for common holes.  For instance,
      it checks that the owner of the directory where the script is
      found also owns the script.

   3. If you call cgiwrap as cgiwrapd then you'll get special debugging
      output; I've found this extremely helpful in testing.

Nothing is bulletproof.  The simple act of letting users create static
html documents is itself something of a risk.  For example, on many
UNIX-based WWW servers, any user can type the following:

cd ~/public_html
ln -s /etc/passwd Read_This_Folks
                  ^^^^^^^^^^^^^^^or whatever ;-)

And you've just let the entire universe see your system's password
file!  Of course, this is monumentally stupid, and of course many
newer systems use shadow passwords, but I'm sure more subtle holes
exist even with static html -- to say nothing of cgi scripts.

Also, take a look at the URL:

http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html

for some _very_ useful information about cgi security issues.

--------
Matthew.Healy@yale.edu  Postdoc (& now, WebMaster)
Center for Medical Informatics, Yale School of Medicine
He was covered with clanking chains of code. "I am the
Ghost of Hacks Past," he said to Scrooge.
http://paella.med.yale.edu/~healy/matt_healy.html