|
|
|
|
|
Why Having the Right Permissions is
Critical (Unix only)
On most servers, you will want to set your permissions as strict as you can while still
allowing your script to perform correctly. If your server is running
cgi-wrap or another wrapper script that allows you to run scripts with
read/write permissions across all directories that you own, then you
may not need to set permissions for your data file at all... it may
just run fine with its default permissions.
If you have an addable script, your password is stored inside the
script itself. Your password is only as secure as your script, so if
people can download your script, they can figure out how to add, edit,
and records in your database.
Windows Servers
If you are on a Windows server on a virtual host, you should consult
your control panel. It should include tools that allow you to
mark a specific directory as one containing executable files.
You may also need to mark your data directory as writeable using the
same control panel.
Setting Permissions using Telnet (Unix only)
If you have a Class A type database, then the only permissions you
need to worry about are those for your script. After transferring your
script to the appropriate directory on your server (usually the cgi-bin
directory), you need to change its permissions. You can do this by
telnetting to your account and typing cd x (where x is the name of the
directory to change to) until you arrive at the directory your script
is in (note: dir or ls should list the current files and
directories). Once there, type chmod 755 x (where x is the full
name of your Perl script). After changing your script's permissions,
you should be able to execute it by simply typing the full name of the
script at the command prompt.
Permissions Summary
- You should chmod 755 your script. Many servers will not execute a
script if permissions for the script or the directory the script is
in are set above 755... there are also security issues involved with
setting permissions for a script above 755.
- You should chmod 777 the directory your data file is in IF you
receive permissions related errors from the script when adding or
editing your data file. Ideally, you should put your data in a
directory that is parallel with your public_html directory and not
inside it, if your server space supports that option. This way, the
script will be able to access your data file, but people will not be
able to access it by typing the URL of it into their browser...
since it's not in your web directory, it doesn't have a URL.
- You should ALSO chmod 777 your data file IF you receive
permissions related errors from the script when adding or editing
your data file.
- It is normally not a good idea to put your data file and script in
the same directory.
Setting Permissions using WSFTP (Unix only)
To change permissions using WSFTP, connect to your account. Click once
using the left mouse key on the file or directory whose permissions
you want to change. Then click once using the right mouse key and
select chmod from the menu. Configure to match numbers above.
CHMOD 755 is the same as checking:
You should always chmod 755 scripts unless your server documentation
specifically tells you otherwise. If you move, rename, or delete a
script, you will need to set permissions for your script again. If you
just FTP a revised script on top of a script with its permissions set,
then you will not have to set permissions for the script again.
CHMOD 777 is the same as checking:
You should never chmod 777 a script or a directory that
contains scripts. On some servers, in order for your script to be able
to write to your data file, you will need to chmod 777 both the
directory that contains your data file and your data file itself.
Again, your scripting directory and your data file generally should not be the
same.
|
|
