• cgi-bin scripts run under the www account, not under the account of the users who own the scripts.
• I can't guarentee the security of users' scripts even if they did run under their own account without looking at those scripts.
• For sites with several hundred users wanting cgi-bin access, it is unreasonable to expect the webmaster to continuously examine and install cgi-bin scripts for everyone.

My solution to this is to write secure cgi-bin scripts that do things that are in demand by many users, and set them up so that a single script can serve the needs of many users. Specific examples I can think of are: (Many of these are obsolete.)

• My www hit counter, although something similar that worked with server includes would be more efficent. (Counters are lame anyway.)
• A simple forms processor that reformats the output and returns it via e-mail or log file to the user that owns the form. I've written something, but it does not currently figgure out the user who owns the form. NCSA httpd comes with a program called 'email.c' that does this, but is hardcoded so that the form must look much like the mailto: style dialog box.
• An imagemap translator that checks a database in the users' directory; I'd write this, but I don't have any imagemaps to experiment on. I've been told that the lastest version of the NCSA imagemap server does this exactly. (Bah. Use client side image map instead.)