Home

CGIWrap - Comments from Administrators



	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. 
	...snip...
	I literally had to re-code parts of suexec to get it to work 
	under my server configuration.
	...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.
-- 

|           "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:
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:
for some _very_ useful information about cgi security issues.
--------