In the UNIX environment, users and programs are given access to files based on a set of "file access permission" attributes associated with each file and directory in the UNIX file system. 

• Two of these file permission attributes are associated with the identity of the file’s "owner," and the association of the file with a "group of users." The third attribute describes the access permissions of any other user who attempts to access a file or directory. 
• Executing programs inherit the user id - specified at login - of the person executing the program, unless changed by the "superuser." 

For those who are not familiar with UNIX file permissions, the document entitled UNIX File Permissions explains how file access is managed in the UNIX environment.  

Where Permissions Are Needed

The WSD installation program creates files and/or directories in the installation directory and in the various support directories. Additionally, WSD requires appropriate permissions to create or update files on the web site after installation.  Unless you are running WSD on a trusted intranet, you probably want all of your files and directories to be read-only to everyone but your login uid ("644" for files and "755" for directories). In many cases you may actually want your files and directories to be invisible to everyone except your login uid ("600" for files and "700" for directories).

Permission Defaults

Most web servers are configured to run with a uid of "nobody" and a gid of "nogroup". Files that are created by the web server (or by CGI applications started by the web server) are normally given Read and Write permissions for the *owner* uid (for example: "nobody"), but read-only permissions for everyone else (a permission value of "644"). Users who update web site content through Telnet or FTP will normally login to the web server with a specific login uid (let's use "johndoe" as the example). Unless you implement one of the UNIX file permission scenarios we describe later in this document, you will encounter the following problems. When WSD (or any other CGI process) creates a file on the web server, that file will be owned by "nobody," the uid inherited from the web server and passed through WSD to the file system. 

This means that only WSD (or another CGI program inheriting the same uid as that used when the file was created) can write to the file. Therefore, our example FTP user, johndoe, can only read the file, not update it. Conversely, if johndoe creates a file using Telnet or FTP, WSD can read the file, but will not be able to update it. Removing this dead-lock requires manipulating assigned file permissions. In an ever-perfect world, you could simply assign read, write, and execute permissions to all users. But, unless the web server is on a trusted intranet, it is not wise to change the file or directory permissions to allow everyone full read and write access to all of the files and directories on your server (represented as "666" for files and "777" for directories).

WebSite Director  Permission Options

There are six possible solutions to the permission problems mentioned above. Each one provides different benefits and drawbacks. Each also has different implementation requirements and some will be more suitable to your specific environment than others. They are listed in what we think is the preferred order from a strict security perspective, with the best solution listed first: 

1. No Telnet or FTP access – This is the preferred solution when there is no requirement to update files outside of WSD using Telnet or FTP. To implement this scenario, the system administrator, or a superuser with root access, must make file and directory permission changes before software installation. 

   Before installation, the ownership of the installation, working, and support directories and ownership of the installation program must be changed to the web server’s uid. We are using a uid of "nobody" for our examples, BUT your server may be installed for a different uid. Please determine your server’s assigned uid before changing any of your file permissions! 

   1. Assign the "nobody" uid and "nogroup" gid to the installation program.
   2. All of the existing web-content server files that will be maintained by WSD must also be changed to the "nobody" uid and "nogroup" gid.
   3. Running the installation program will then install WSD and the supporting files as "nobody" and "nogroup.
      WARNING: All files created by WSD will be owned by "nobody" and "nogroup". Only a superuser will be able to modify or delete those files outside of WSD.
   Note: Although this solution provides the best security of the available options, it also provides the least amount of flexibility. 

2. "Setuid user" – This solution provides the best combination of security and flexibility. To use this scenario the user installing WSD must be able to log in as a superuser, or ask the system administrator to make the necessary permission changes. 
   1. Copy/download the WSD installation program to the installation directory.
   2. Change the ownership of the installation directory to the uid of the login account whose files will be maintained by WSD (using "chown <account <directory" and "chgrp <group <directory").
   3. Change the ownership of the installation program itself to the same uid (with "chown <account <program" and "chgrp <group <program"). 
   4. Give the installation program setuid and setgid permissions (with "chmod 6755 <program")
      Note: When the installation program is run by the web server, it will switch from the "nobody" uid to the login account uid and will unpack the various WSD files and directories as that user.
   5. Run the installation program from your web browser.
   6. After the installation is complete, give the WSD program file itself ("wsd" or "wsd.cgi") setuid and setgid permissions (with "chmod 6755 wsd").
      Note: When WSDis run by the web server, it will create and update files with the same uid as the login account uid.

3. Dedicated web server – This scenario applies if you are setting up or using a dedicated web server. This solution also applies to some ISP and web hosting provider environments, where a separate copy of the web server is run for each account. 
   1. Configure your (copy of the) web server to run with the uid and gid of the login account, instead of "nobody" and "nogroup".
      Note: When the web server runs as the login uid, then all CGI programs started by the web server also run as the login uid and there are no permission issues at all.
   2. Ensure that the web server has access to the installation directory and execute privileges for the installation program.
   3. Run the installation program from your web browser.
   Note: While there are some security advantages to running the web server as "nobody" and "nogroup", there are drawbacks to this option that need to be considered. If you allow "unsecure" CGI scripts or programs to be run from your server, they could cause security breaches by performing actions allowed to a uid with more access permissions than those typically assigned to "nobody." 

4. Apache suEXEC – The suEXEC feature, introduced in Apache 1.2, provides Apache users the ability to run CGI programs under user Ids different from the user ID of the calling web server. This scenario provides a stronger solution, from a security perspective, than the use of CGIWrap described in the next section. 

   Used properly, this feature can considerably reduce the security risks created by allowing users to develop and run private CGI programs. Please note that the Apache group provides the following disclaimer at: http://httpd.apache.org/docs/suexec.html

   "… if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer’s security. If you aren’t familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC."
   suEXEC is based on a setuid wrapper program, called by the Apache web server, similar to CGIWrap, but with significantly greater restrictions. This wrapper uses a very sophisticated and highly restrictive process to determine whether a process can be safely executed. Go to: http://www.apache.org/docs/suexec.html for instructions on setting up and configuring suEXEC. 

5. CGIWrap – This is a viable alternative when the installer is not able to log in as a superuser or if the system administrator is not willing to make the necessary permission changes, as is the case on many ISPs or web hosting sites. The major drawback to this scenario is that CGIWrap needs to be installed by the system administrator and must be configured to run as a superuser. 

   Note: If CGIWrap is not already installed, your system administrator may not be willing to install it for you because of security concerns caused by CGIWrap’s requirement to run as a superuser. 

   CGIWrap must be configured to run as a superuser and given setuid permissions. CGIWrap is invoked as part of a browser URL that specifies a program to be executed. The user must include a login uid as part of the URL used to invoke CGIWrap. CGIWrap then switches identity from the assigned superuser id to that of the login uid assigned to the program (which only a superuser can do) before running WSD or the WSD installation program. 

   Note: Before running the WSD installation program, CGIWrap must either be installed in the WSD installation directory or a symbolic link for CGIWrap must be set up in the WSD installation directory. 

   CGIWrap command and invocation parameters must be included in the URL entered to run the installation program and in the URLs entered to run WSD and any other WSD-related processes. Go to: http://wwwcgi.umr.edu/~cgiwrap/ for specific instructions on installing and configuring CGIWrap. 

   WARNING: Because CGIWrap runs as a superuser, there are numerous security concerns involved that need to be carefully considered before using this option. 

6. Full Access File Permissions – This is the option of last resort, when none of the previous solutions are available to you. In this scenario, you give the WSDinstallation program and all of the installed WSDsupporting program the ability to manipulate content by giving full (read, write, and execute) access to literally "everyone," including the "nobody" uid. That means you must use the "chmod" command to give everyone access to the directories and files ("666" for files and "777" for directories). 

   WARNING: The following instructions require you to be the "owner" (uid) of each/all of the files and directories listed, or a superuser with root access. 

   1. Create the "working directory" if it does not already exist.
   2. Use "chmod 777 <working-directory-name" to make it writeable by anyone.
   3. Create the WSD support directory (default is "wsd-support" directly under the document root directory) if it does not already exist.
   4. Use "chmod 777 <support-directory-name" to make it writeable by anyone.
   5. Use "chmod 777 <installation-directory-name" to make it writeable by anyone.
   6. Install WSD from your browser.
      WARNING: You must check all of the check-boxes in the WSD installation option "File Permissions for new files" so that WSD will create files that can be updated by anyone.
   7. Use the "chmod" command to allow everyone write access to ALL of the files in the working directory that WSDwill maintain, using "chmod 666 <file-identifier(s)" iteratively until all of the files can be accessed by anyone.
   8. Use the "chmod" command to allow everyone write access to ALL of the directories under the working directory that WSDwill maintain, using "chmod 777 <directory-identifier(s)" iteratively until all of the directories under the working directory can be accessed by anyone.
   Final Warning for this scenario: On a shared server, setting these permissions means that any user with login access to the server can update or even delete any of the files or documents maintained by WSD! Therefore, this option should only be considered on an intranet server where access is strictly controlled!