Knowledge base: Using CGI

  1. Key Information
  2. Script Paths
  3. Setting Permissions
  1. Key Information

    Our servers operate a highly secure CGI environment which protects your scripts and associated data files from the nosey eyes of other users on the web server. Because of this, some standard scripts may need slight modifications of file and directory permissions to those suggested by the script authors. This section is a guide to how to ensure all your CGI scripts run smoothly. Please also give this information to any third party developer who may be installing or writing CGI scripts on your behalf.

    You should note the following key information about CGI scripts on your Positive account:

    1) Scripts can run from anywhere

    On your Positive Internet account CGI scripts may be located anywhere within your webroot. in other words anywhere within public_html or a sub directory thereof. Your don't have to run scripts from a cgi-bin directory, although for legacy code reasons you may create a cgi-bin directory if you wish. Many people prefer to create a directory called 'cgi' and place all their scripts in there, but this isn't essential either as you can place scripts wherever you please.

    2) Scripts MUST be uploaded in ASCII format

    All CGI scripts must be uploaded via FTP in ASCII transfer mode, not in binary transfer mode, or else they will become corrupted and won't run. This is one of the commonest causes of script failure that we encounter, so always check that your CGI scripts are uploaded in ASCII transfer mode. This is usually easily set for most FTP clients. If using a publishing tool such as Dreamweaver, you'll probably want to configure the software so that all files with a .cgi or .pl extension are uploaded in ASCII transfer mode. NOTE: you cannot use ASCII transfer mode for all your web files, as images will corrupt if not uploaded in binary format.

    3) Scripts MUST have the correct permissions

    Ensure your scripts are set as readable, writable and executable only by you - if you don't then the web server will not execute your CGI scripts. You must follow the following guidelines when setting permissions on CGI scripts:

    • All CGI executable files (e.g. files ending in .pl, .cgi etc) must have their permissions set to either 700 or 755. You can do this via SSH (secure telnet) with the command 'chmod 700 filename' or via most FTP clients (by setting them to read-write-execute for user only).
    • All files that need write access (such as counter log files, message board files, guestbooks etc) should have permissions set to either 500 or 755. 
    • Any directories containing scripts should be set to 755 (they usually are by default anyway).

    Our servers will not run a CGI script which is deemed to have insecure or too open permissions. For this reason, setting a script up which can be executed or written by all users will result in a script which refuses to run. In general if a script's instructions tell you to change permissions to 777, you will almost certainly find that the script will not run. You should ignore the script's instructions and use 700 or 755 instead - it is safe to do so and indeed recommended as our method provides better security. Watch out in particular for directory permissions, these should always be set to 755.

    Please don't hesitate to email us if you have a script problem which you feel is related to permissions or other server issues, we will do our best to advise you on the best permissions for a script. We can't of course support just any script, as scripts can vary in standard and readablitiy, however we will certainly be able to rule out a server problem and best advise on steps to take to try to get scripts working.

    Back to top

  2. Script Paths

    When setting up scripts you will often be asked for the paths to certain applications or tools on the server. Here's a few of the most common ones required by many scripts:

    Path to Perl

    The path to Perl for all scripts written using the Perl language should be set at the very top of the script as follows:


    Path to Sendmail

    Our mail server is Qmail which is a secure, fast and reliable alternative to the more standard sendmail software. However, where CGI scripts are concerned, Qmail does fully emulate sendmail as much as possible, so normally alterations to scripts should not be required. Our mail server can therefore be called from within a CGI script as:


    Qmail understands the commonly used sendmail options.

    PHP in CGI Mode

    If you wish to use PHP in CGI mode, to take advantage of the security benefits, simply add the following line to the start of your PHP files:


    And enclose your php commands within <? and ?> tags.

    Using this method you can set the file name to .cgi instead of .php and then set permissions to 700.

    Back to top

  3. Setting Permissions

    Here's an example of how to set file and directory permissions on a CGI script.

    If you have a script named fish.cgi, you would ensure that it had proper permissions by SSH'ing into your account, using the cd command to move into the directory containing the script and issuing the command:

    chmod 700 fish.cgi

    Alternatively, use your FTP client to set permissions to 700, or read-write-execute for use only.

    To check this has worked, obtain a long directory listing using the ls -l command via SSH (or with an FTP client capable of showing file permissions). You should see something similar to this:

    -rwx------ 1 fbloggs fbloggs 17009 Jul 20 2001 fish.cgi

    (Note: bloggs is the account username in the above example. In reality your own username would appear there)

    The directory containing the script should be given the appropriate permissions as well. The correct permissions are normally set by default when you create a directory, but it's worth checking to be on the safe side. So, for the above example, assuming you are in the directory containing the fish.cgi script, simply type:

    chmod 755 .

    Note the space and dot after the 755. This makes sure that files in this directory cannot be written to by anyone but yourself.

    Back to top