Some Important Notes About Permissions

TYPICAL PERMISSION SETTINGS:

Executed via the web by anyone: chmod 755 (rwxr-xr-x)

Executed only through the command line: 700 (rwx------)

Library files: 644 (r-wr-wr-w)

World writable: 777 (rwxrwxrwx) -- this is not necessary on our servers and will only work on files that are placed outside of the cgi-bin directory.

This machine is running suEXEC through the Apache® webserver. This effects how file permissions are set. This automatically makes the 777 (rwxrwxrwx) permission return an error when applied to file permissions. Perl scripts will not work if file's permissions are 777.

Files that would otherwise require world write access (writable files) do not have to have this permission (777 or rwxrwxrwx). Since the Perl script which will open and write to the file is executed under the owner's userid, and the file is also owned by the same user, the file only needs to be writable by owner, not world.

Finally, there are some freeware or perhaps even commercial Perl scripts which may require you to set a directory to rwxrwxrwx (chmod 777). Again, this is not necessary. Setting the directory permissions to 755 should always be sufficient. If you do set any directories to rwxrwxrwx, then any Perl scripts located inside of this directory will not execute!

If your program does require that you change the permissions of the program's directory to 777 (rwxrwxrwx), make sure that you separate the program from your other cgi programs. Make a new directory, put it outside of the cgi-bin, but do not change the permissions of your cgi-bin to 777. This will cause all of the other scripts in www.yourdomain.com/cgi-bin to fail. Do not change the permissions on your cgi-bin directory.

If you have already changed the permissions of your cgi-bin, you need to change it back to 775 (rwxrwxr-x) or 755 (rwxr-xr-x).

While troubleshooting your scripts, you may be tempted to change everything to 777 (rwxrwxrwx), but if you do, remember that this setting offers absolutely no security. Once your program is complete, remember to change your permissions to whatever is the most secure setting while allowing the program to still function.

NOTE: HTML documents are not viewable from within the cgi-bin directory structure. If your program is writing to an HTML file, that file must reside within the www directory structure, but outside of the cgi-bin directory.

Back to the top

Incorrect Path to PERL

A very common problem. The first line of your program needs to be the correct path to where perl is installed on your server. On all servers, this path is correct:

#!/usr/bin/perl

Uploaded in BINARY Format

This is another common problem -- the fix is just to re-upload the file in ASCII format. You'll need to consult your FTP program's documentation to figure out how to switch modes.

ASCII mode needs to be used for text only documents, which include *.txt, *.cgi, *.pl *.css, *.html, etc.

BINARY mode is used for non-text items, such as executables (*.exe), zip files (*.zip), image files (*.jpg, *.gif) and the like.

Back to the top

Incorrect Program or Library Paths

If you need to use the server path to programs, make sure that it is in the following format:

/home/yourdomain/pathtoyourprogram

The first slash is necessary. A trailing slash may or may not be required, depending on the program.

Unescaped @ or "

There are several special characters that PERL uses to perform specific functions, for example: @ $ " . Internal Server Errors will definitely occur if you have an unescaped @ or " in your variable definition. (An unescaped $ within a variable definition or subroutine usually will not cause Internal Server Error, but may make your program behave contrary to the way you want it to).

As PERL reads through the script, it will look for these characters and try to execute a command based on it. As you may already know, the @ is used to define arrays, the $ is used to define variables, and the " is used to enclose variable definitions. For this reason, if you want to use any of these symbols within your variable definitions, you have to "escape" them.

Escaping is simply adding a backslash before the special character like this:

me\@mydomain.com

he said \"something or other \"

so your final variable definition will look like:

$orgemail="me\@myisp.com";

$a_useless_message="So he said that \"I really need to escape that quotation mark\"";

Not escaping these special characters will cause an error in your program when you try to run it.

 

Incorrectly Closed Subroutine, Line or Library

All subroutines begin with a { and end with a }.

Most lines must end with a ;.

The last line of a library (a file that does not actually perform any function, but lists variables or contains only subroutines) must be 1;. This is because each file in the program must return a true value. Placing this 1; on the last line does this.

Back to the top

Incorrect Operating System

Our servers are running Apache on Linux. Programs designed to run on other operating systems can either function properly, not function properly, or not work at all, producing Internal Server Errors. Please make sure that the program you are attempting to run is intended for a Unix-based server.

Back to the FAQ