## CGIWrap - Comments from Administrators

    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 URLs:

    http://www.umr.edu/~cgiwrap/
    ftp://ftp.cc.umr.edu/pub/cgi/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