File Permissions on Cloud Sites
Directory permissions in a shared environment are exponentially more important than in a dedicated environment. The environment uses shared resources, but to keep those resources protected, you must enforce strong file level access controls. Cloud Sites treats the content storage as a UNIX file system. UNIX file permissions can set ‘who’ can access a file, and ‘what’ that access level is per ‘who’.
The ‘who’ is one of three categories: user, group, other. The ‘user’, abbreviated as ‘u’ is generally the person that created the file. Another common term for ‘user’ is ‘owner’. I believe that ‘owner’ is more clear, but the abbreviation for ‘owner’, ‘o’, would conflict with ‘other’. The ‘group’, abbreviated as ‘g’, is anyone who belongs to the same group that the file is assigned to. By default, when a file is created it inherits the same group membership as the default group of the creator. The ‘other’, abbreviated as ‘o’, is everyone else and is often referred to as ‘world’, because it’s the rest of the world. User, group, and other are collectively referred to as ‘UGO’.
The ‘what’ is any of three categories: read, write, execute. Collectively, these are referred to as ‘RWX’ –think eXecute. These attributes have slightly different context for files than for directories. RWX for Files: For a file, read is the access to view the contents, write is access to modify the contents, and execute is the ability to execute the file. In UNIX, files have to be marked as executable to alert the shell to treat it as a binary or search for an appropriate interpreter to execute it. On Cloud Sites, all of the scripts in the CGI directory must be marked as executable. These are all pretty straight forward. RWX for Directories: For a directory, read is access to list the contents of the directory, write is access to add or remove entries from the directory, and execute is access to traverse the directory. If you think of a directory as nothing more than a special file that contains directory entries, then read and write make more sense. Having write access to a directory allows you to edit the directory entries, adding or removing entries. This does not mean that you could edit the contents of the file, that would require write access to the file, but you could remove its entry from the directory. The execute access on a file controls two things. If a directory is not set execute, then you cannot ‘cd’, change directory, to it. Also, if a directory is not execute, it acts as a road block for directories below it, preventing access to change to any directory below it, regardless of their permissions.
Representing Access with Numbers
Three digits represent all file access controls for UGO, one digit for each. The RWX are squeezed into a single three bit wide digit using a technique called bit-mapping. In bit-mapping, each bit has special meaning that represents a value of either ON or OFF. I have included an illustration for a quick overview of binary.
The three ‘what’ are assigned a single to bit in the following order from high to low: read write execute. Three bits(binary digits) can represent any 8 values 0-7. Dealing in a range from 0-7 is called Octal, as opposed to dealing with 0-9, which is called decimal. Read is in the 4’s column. Write is in the 2’s column. Execute is in the 1’s column. The following table can be used as a reference:
Each ‘who’ is given one of these octal bit-maps in the following order from high to low: User Group Other. So each ‘who’ has a way to represent, in octal, the read, write and execute access for it. Hopefully this illustration below will clear it all up.
A single octal digit represents the RWX on/off values. Three of these octal values represent all three of the ‘who’. So, the number 777, is not literally seven hundred seventy seven, it is actually 7, 7, and 7, where each octal digit indicates that all three bits have been set ON (4+2+1 = 7), thus giving full permissions to User, Group and Other.
When the file is created, it takes its owner as the person who created the file, and its group as the default group of the user that created the file. The permissions are set against a mask(think mask like masking tape) that may specify whether certain bits, and thus permissions, should be turned OFF by default. Most services, such as FTP or Bash, mask OFF the world writable bit, making it impossible to create a file that is world writable. The Rackspace Cloud Sites FTP and SFTP all behave in this manner. The owner can change the permissions after file creation to anything from 000 to 777. Herein lies the problem. Within the Rackspace Cloud Sites environment, there is no good reason to ever give ‘other’ write permissions to any file or any directory.
Cloud Sites Scenarios
Cloud Sites is continually working to improve security. At the current state, there are a few special cases that the end user needs to know about to properly secure their files. 1. Using Cloud Sites only as a PHP solution one can completely remove all ‘other’ permissions from all files and directories. So files could be 600 and directories could be 700. 2. When using multiple FTP users to manage the content of the site, the Group permissions must be considered. FTP users are in the same group as the primary account owner. Their ability to access files is determined through the Group permissions, and in general they should be set the same as the User permissions. 770 is standard for directories, and 660 is standard for files. 3. When using CGI, the CGI files must be set Executable. So 700 or 770 is the standard for files in the cgi-bin directory. 4. Using Cloud Sites classic ASP/.Net solution users are strongly encouraged to use impersonation. Please contact our support for assistance with this. The table below can be used as a reference for each scenario mentioned above.
|Dir||700||RWX||---||---||Gives only the owner full permission. Good option if you are not using FTP users.|
|File||600||RW-||---||---||Gives only the owner full permission to the file that is not a script or a binary. Good option for all content outside of CGI when not using FTP users.|
|Dir||770||RWX||RWX||---||Gives group and owner ownership the full permissions. Good for when using FTP users.|
|File||660||RW-||RW-||---||Gives group and owner access full permissions. Good for files outside of CGI, when using FTP users.|
|File||700||RWX||---||---||Gives owner full permissions and marks the file as an executable. Good for CGI bin and no FTP users.|
|File||770||RWX||RWX||---||Gives owner and group full permissions and marks the file as executable. Good for CGI when using FTP users.|
|Dir||755||RWX||R-X||R-X||Gives owner full permissions and allows everyone else to traverse and list directory contents. Required when using .NET w/o impersonation.|
© 2011-2013 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
See license specifics and DISCLAIMER