DiscusWare, LLC.
Download Purchase Contact Us
Home
Support Home Documentation Knowledge Base Support Forums Support Request Advanced Services
Safeguarding your Discus data on a shared server

Tips for those installing Discus on a shared server, to prevent the actions or scripts of other users on that server from destroying data on your Discus board (or the rest of your web site).
Support Site Search
 

Support Policy: DiscusWare provides this document for the instructional benefit of our customers. However, we do not provide support for any of this. If you have questions, or if you break something, you will need to ask your web host for support!

Overview of Shared Server Hosting

Many Discus boards are hosted on shared servers, meaning that your site is hosted along with a whole bunch of other sites on the same machine. Unfortunately, when this is the case, errors made by other users or security holes in scripts deployed by others may cause damage to your web site. And also unfortunately, several well-known CGI scripts (including other discussion boards) have equally well-known security flaws that are routinely exploited to damage web sites.

Since switching to a dedicated server is expensive or is otherwise impossible, we offer the following guidelines to help protect yourself against data loss caused by the errors of others:

What unix permissions mean for directories

The most common mistake of others, or exploited security hole in a CGI script, is to run the command rm -rf /. This command tells the server to start at the root directory and recursively remove as many files and directories as it can. Obviously, this does heavy damage whenever it encounters a directory or a file that it is allowed to remove.

Unix directory permissions are typically represented in notation such as rwxr-xr-x. There are three sets of three letters or symbols.

  • Red: Permissions for the owner of the file

  • Green: Permissions for anyone who is in the same group as is assigned to the file, who is not the owner of the file

  • Blue: Permissions for 'other' -- anyone who is not the owner of the file and who is not in the same group as is assigned to the file

Within each of these three sets of letters and symbols, the following appear:

  • r: Reading permissions. For directories, this means that the contents of the directory can be listed.

  • w: Writing permissions. For directories, this means that you can add new files to the directory or you can remove files from the directory.

  • x: Execute permissions. For directories, this means that you can 'cd' into the directory and look at files and directories in the directory. There is pretty much nothing you can do if execute permissions are not enabled.

The "write" permission is the most misunderstood setting. Write permissions on a directory means that you can add or remove files from the directory. However, your ability to change the files in the directory depends on the permissions of the file itself, not on the permissions of the directory. Thus, it is still possible to write to files in a directory that itself is not writable.

The rm -rf / command requires a directory to have all three of read, write, and execute enabled for the user performing the command in order to have its maximum destructive effect. If 'read' is not enabled, the command cannot list the files in the directory and thus will not continue to descend the directory (but the directory itself will be removed if it's empty). If 'write' is not enabled, the command cannot remove files or directories from that directory itself (although it still may get into subdirectories that themselves may have the 'write' attribute enabled, and remove files there). If 'execute' is not enabled, the process pretty much stops there, since it can't change into the directory to continue its operation.

How does this help me?

Depending on the configuration of your server, this may help you a little bit or a lot. In order for your web site to work properly, you need to be concerned about the three "people" who need access to the files on your site:

  1. Yourself: As the owner of your files, you want to be able to add new files, delete files, create new directories, and modify existing files. Thus, for the owner section of the permissions, you should generally always use "rwx". The only person to whom these permissions apply is you (or anyone else who knows your password).

  2. Web server, not scripted: The web server itself must have the ability to read your HTML files in order to display them to the visitors of your web site. Since the web server generally does not run as you, and it's generally not a member of your group, you will generally need to enable the execute bit (x) of the 'other' permissions set (the last group of three characters/symbols). If you want the web server to be able to create a directory list, you also need to enable the read bit (r) of the 'other' permissions. More on the write bit below.

  3. Web server, scripted: The configuration of web host servers with regard to the user that the web server runs as when it's executing a CGI script varies. Generally it's one of these two (you can ask your web host which):

    • Web server runs as unprivileged user: This means that everyone's scripts on the server are executed as 'nobody' (the username can vary). What's generally true is that this user ID is not you and is not a member of your group. Thus, to allow the server to write to files (such as Discus message files and administration files), you need to make certain files and directories "world writable." But this is inherently less secure, since you are opening up those files and directories to being written by everyone's CGI scripts (which may or may not be secure) and also everyone's account (so anyone typing rm -rf / can wipe out much of your data).

    • Web server runs as you: If your web host is using a technology such as CGIWrap or Apache's SUExec, when a CGI script is run on your site, it runs under your user ID. This means that the script can do anything that you can do. It also makes it possible to secure your data against the actions of others -- our document on How to modify the permissions that Discus uses for its directories and folders tells you how to do this.

What steps can I take to help?
  • Make your home directory non-readable to others

    You can protect yourself against a general rm -rf / command by changing your own home directory to remove the ability of "other" to read files in your home directory. As noted above, this prevents the command from building up a list of files in your directory (but it still allows the web server to get at files under your directory when it knows where they are).

    Possible caveat: If your home directory is also the starting point for your web site, you may get a 403 (forbidden) error if "index.html" is not typed in after your domain name. If you rely on directory listings in the main directory of your web site, this may also break.

    How to do it:

    • Be sure to note what the permissions were before on the directory, so if this change breaks something, you can revert to the original.

    • With telnet access, type the command: chmod o-r ~

    • Without telnet access, use your FTP client. If you can 'cd' one level above your home directory, do so. Then choose to change permissions on the directory. Try permissions of rwx--x--x (numeric 711).

  • Contact your web host

    If you are concerned about security, ask your web host to install CGIWrap, SUExec, or another package so that your CGI scripts will run under your own user ID. Then modify the permissions that Discus uses for its directories and folders to apply this security.


Download Purchase Contact Us
Privacy Policy
Copyright © 2005, DiscusWare, LLC, All Rights Reserved