One year ago this month, Stephen wrote an article concerning the basics of setting UNIX file permissions in order for a CGI (Common Gateway Interface) script to perform properly. If you are unsure in the least of what I'm talking about, make sure you read his article.
Almost every CGI script you come across, and there are thousands out there, will have a reference in their "readme" or install files pertaining to making a particular file or folder 'world writeable' or chmod 777. From a simplicity standpoint, the 777 permissions basically say that anyone that gains access to the file, can read, write, and execute the script. In today's advanced society, where hacking is commonplace, hosts are becoming very leery or not allowing it at all due to security issues. With web hosts becoming stricter and not allowing world writeable files, this brings most CGI and even some php scripts to a screaming halt; or does it?
Unfortunately for many of us, knowing nothing more than basic FTP uploading and the setting of file permissions for a script is the extent of our knowledge. With many hosts not allowing the 777 permissions, and more doing so every day, it doesn't necessarily mean that our use of scripts is extinct. If and only if your host has set-up the server properly, and we're only talking about UNIX based machines here, a world directory or file does not need to be world writeable. Some coders and even hosts will disagree with this but we personally use a host of this nature, and we use a multitude of scripts.
Web hosts are more advanced today than they were even just a year ago; the days of having to telnet into your account to add an .htaccess file are almost gone, and it won't be too long before having to set your file's permissions will be too. The proliferations of hosts now or already having implemented such programs like web based control panels, phpMyAdmin, and SBOX only verify these facts. As in the case of our host, even the main path to perl doesn't need to be changed; it recognizes the script and automatically determines the path for it; and our sendmail path too.
Our biggest hurdle with these advancements (remember, we're talking about hosts that do not allow 777 permissions) is when we encounter some sort of internal server error, such as 500 errors, 403, and so on. Again, if the host has the knowledge and has set-up the server correctly, we usually find the script to be of the problem in one form or another; which is the case with either type of host. The majority of the time we have not set a variable or path correctly. In some of the more advanced cases where some of us are more adept at modifying a script (hack as they call it) for HTML or other purposes, we may have deleted a variable or added something as simple as a quotation mark. The last option is the fact that the script itself may be the problem and no matter what you or the server does, it just isn't going to work.
In either of the former instances, we need to look at the error logs before thinking the server or your permission is the culprit. I don't want to get into troubleshooting scripts as it is too diverse of a subject but at least you understand what basic steps to take when using a host such as this. Don't get me wrong here, you do need to set permissions, it's the files needing to be set world writeable that we're talking about. What calls for a 777 permission, can be used just fine with 755 permissions. What calls for a 777 ... can be used just fine with 755 permissions.
When you incorporate scripts, you'll need to ask your host or prospective host a few questions. The first and foremost question being "do they allow world writeable files and directories (folders)?" if not, how does the server handle it? (If they allow CGI at all). You truly don't need to know the specifics; you just don't want to be banging your head against a wall because that custom script isn't working. This also includes some php scripts as well; which we recently encountered a problem with. In the end, we found the problem with how it was coded and not a permissions setting (it called for 777 settings). Here is where your selection of scripts is a very important point, if you select a script that has minimal or no support (particularly free ones), then you're asking for trouble and you will possibly wind up spending money for the hosts support personnel to help locate and solve the problem. Which again, can happen with any host whether they allow 777 permissions or not.
While all this sounds troublesome, the true fact is, it makes your scripts much more secure. Making a file world writeable is similar to leaving your image directory completely open for access. With the help of good support technicians, your scripting problems are less than that of what you would encounter normally. It's been drilled into us as users that world writeable permissions are needed, and today it is not so with the proper host. The argument over using programs that "help" or determine how scripts execute are resource intensive and slow servers or even that they're costly, is moot. With properly maintained hardware, good Net connections, and systems that are not overloaded, you will never see a difference in how your site is served.
That's what a good host is supposed to be anyway, one that provides knowledgeable support, uptime, and looks out for its clients security as well as it's own. In choosing a host for a site that incorporates scripts, no matter whether it's only a link submission form or a full bore personals site, all parties security especially sensitive data, should be considered.