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. --------