Security

Introduction

This article is a compilation of Linux file permissions along with related commands and explanations. Content has been compiled from online articles as well as forum posts. Where appropriate, explanations from forum posts and articles (i.e., Rackspace , Redhat, and University of Surrey) are modified to provide better clarity or to correct errors. Finally, links to the resources used to compile this article are interspersed throughout and are summarized in the references section.

Default Permissions for Linux Directories and Files

Default permissions are applied automatically upon directory and file creation. Here’s a detailed explanation:

Default, ‘somewhat secure’ permissions are commonly 755 for directories and 644 for files – no execute permissions, everyone can read, and only the user can write – you will note that the vast majority of files on a Linux system have these permissions. source: cyberx86 on Severfault

Basics: Who and What is a ‘User’ on Your Server?

The user is not the person who is logged into your application – that, and their role in the application (admin, etc) is completely irrelevant to the scenario. The user is the Linux system user [e.g., apache, php] that the process runs under. source: cyberx86 on ServerFault

Symbolic Values and Positions: d rwx rwx rwx

The first slot indicates the file type. The remaining slots are permissions for three categories of users: the owner of the file, the group in which the file belongs, and others – meaning other users on the system who are neither an owner nor a member of the group associated with the file. source: Redhat

The table below summarizes symbolic positions, permission values, and user types:

File Type Owner (i.e., File Creator) Permissions Group Permissions Other Users (i.e., World) Permissions
d/l/- rwx rwx/s/S rwx/t/T
File Types: d = directory, l = symbolic (sym) link that points to another file, - = file

Chmod Octal (i.e., Numerical) Bit Values for Files and Directories

Furthermore, each permission setting can be represented by a numerical value:

Read Write Execute None Granted
r = 4 w = 2 x = 1 – = 0

When these values are added together, the total is used to set specific permissions. For example, if you want read and write permissions but no execute privileges, you would have a value of 6; 4 (read) + 2 (write) = 6.

Why Files and Scripts Do Not Need Execute Permissions

Interpreted scripts (e.g. Ruby, PHP, Python) work just fine without the execute permission. Only binaries and shell scripts need the execute bit. Stated differently, Ruby, PHP, and Python files are not directly run, but rather are read into an interpreter. Thus, only read permissions are needed to run a typical script (one that doesn’t write anything).

source: ServerFault

Understanding Directory Permissions

Deleting a file is controlled by the write permission on the directory. That is, write access for a directory allows deleting of files in the directory even if the user does not have write permissions for the file!

Permission Action chmod option
source: Ubuntu Help Docs
read View contents (i.e., ls command) r or 4
write Create or remove (i.e., delete, move, or rename) files from directory w or 2
execute cd into directory x or 1
1. read restricts or allows viewing the directories contents, i.e. ls command
2. write restricts or allows creating new files or deleting files in the directory, i.e., rm, mv, touch
3. execute restricts or allows changing into the directory, i.e. cd command

A. Group Execute: The Set Group ID (SGID) Bit d rwx rws rwx

SGID bit on directories will make the group association of new files match the parent directory settings rather than that of the file’s creator.

When a file is created, it normally inherits the group (i.e., the group ID and the associated permissions) of whoever created it. But sometimes you want new files to inherit the group id of the folder where they are created. Hence, you would enable the SGID bit on the parent folder to force all created files to inherit the parent folder’s permission settings. sources: ServerFault and ServerFault

Two-part Example Using the SGID Bit (rwx or s or S)

Where:

  1. x symbolizes non-SGID execute
  2. s symbolizes SGID execute
  3. S symbolizes SGID without execute

In the following example we first make the public_html folder belong to the the www-data Apache group:

$ sudo chgrp -R www-data /home/demo/public_html

Next we ensure that all subsequent files (and folders) created in the public_html are automatically added to the www-data group, regardless of what group the creator belongs to:

$ sudo chmod -R 2750 /home/demo/public_html
Notes and Power Tips

The -R makes changes recursive. This applies changes to all files and directories within /public_html (i.e., everything underneath your target folder).

The 5 means that the www-data group (i.e., Apache) may only read (octal bit 4) the directory (i.e., view contents via ls) and execute (octal bit 1) the directory (i.e., cd into the directory).

source: Rackspace New link from Rackspace

B. Others Execute: The Sticky Bit d rwx rwx rwt

The sticky bit is set on directories and affects permissions that users (and groups) have with respect to files and sub-directories.

When the sticky bit is on, only the owner (and of course the root user) of files within a directory can move, delete or rename a given file. Stated another way, the sticky bit prevents other users from moving, deleting and renaming an owner’s files.

The sticky bit is noted symbolically by either “t” or “T”. It is positioned in the “other” users in place of an “x” or a “-“, respectively.

“x” symbolizes non-Sticky execute. “t” symbolizes Sticky execute, while “T” symbolizes Sticky bit without execute. Source: Rackspace

C. Set User ID (SUID) Bit

Rarely used, so will not be discussed. Refer to Rackspace for general usage

Directory Permissions Example: Using All Octal Bits (i.e., Positions)

For the below examples, we read octal bit positions from left to right. In the real world, when only 3 octal values are given, an “invisible” zero at the first octal bit position is implied. Lastly, realize that the first octal position can also have 8 distinct values (0 through 7), however for the sake of simplicity we will only examine the first four values.

For scenario “a” we want to specify directory permissions as follows:

  1. The directory Owner and the Group may:
    1. view directory contents (i.e., ls command) (octal value = 4, symbolic value = r)
    2. create or remove (i.e., delete, move, or rename) files from directory (octal value = 2, symbolic value = w), and
    3. cd into directory (octal value = 1, symbolic value = x)
    However, Others have no permissions:
    2. sudo chmod 0770 /home/shared_directory
    OR 
    sudo chmod 770 /home/shared_directory
  2. Same as scenario (a), but only the owner of the file may delete, move, or rename it: 
    sudo chmod 1770 /home/shared_directory
  3. Same as scenario (a), but all new files added to directory become members of same group as the directory itself and not of the file owner who adds the new file.: 
    sudo chmod 2770 /home/shared_directory
  4. Same as scenario (c), but only the owner of the file may delete, move, or rename it: 
    sudo chmod 3770 /home/shared_directory

Explanation of Values in the First Octal Position

A 1 in the first position of the chmod command is the sticky bit which prevents deletion of a file (i.e., removal or renaming) by anyone other than the owner.

A 2 in the first position of the chmod command is the Set Group ID bit (also known as setgid or SGID bit) which forces all new or copied files to have the group permissions of the parent folder.

A 3 in the first position of the chmod command is the combination of the sticky (1) and SGID (+2) bits.

source: Ask Ubuntu

Change Owner (chown)

For information on chown, UnixTutorial.org has an explanation with examples on the differences between chmod and chown