---
title: "Permissions overview"
date: "2014-10-28"
category: "guides"
slug: "permissions-overview"
---

Every file and directory on a Linux system has a set of permissions that control who can read, write, and execute it. Understanding permissions is essential for managing file access, especially when running web applications.

## Reading Permissions

Here is example output from a directory listing:

```
-r--r--r--    root   root 1972 Oct 13 23:14 test.mail
-rw-r--r--   admin  admin 4345 Aug 29 12:33 test.php
-rwxr-xr-x  nobody  admin  592 Sep 25 10:20 test.py
drwxrwxrwx   admin nobody 4096 Jul  9 10:28 tmp
```

Three files and one directory are shown. Directories are indicated by a leading `d`. Each entry has a permission string, an owner, and a group.

## Permission Types

Permissions are divided into three types:

- **r (read)**: View file contents or list directory contents
- **w (write)**: Modify a file or add/remove files in a directory
- **x (execute)**: Run a file as a program or open a directory

A dash (`-`) indicates the permission is not granted.

### Permission Groups

Each file has three permission groups applied in order:

1. **Owner**: The user who created the file
2. **Group**: Users who belong to the file's group
3. **Other**: Everyone else, including the web server (`apache`)

For example:

```
-rw-r--r--   admin  admin 4345 Aug 29 12:33 test.php
```

The owner (`admin`) can read and write. Group members and all others can only read.

> **Note:** A directory with only execute (`x`) permission (no read) is still accessible if you know the exact filename inside it. This is useful in multi-user accounts to prevent directory listing while still allowing access to known files.
>
> Conversely, if a directory lacks the execute bit, neither it nor any directories within it can be opened.

> Files created by users on your account share the same group (the primary account username). Files created by web applications are owned by `apache`. A nightly task adjusts permissions so the primary account holder can modify these files. Ownership can also be changed via **Files** > **File Manager** > **Properties** in the control panel.

## Octal Notation

Permissions can be represented as a 3-digit number. Map each permission to a value: **r=4, w=2, x=1**, then sum each group:

| Permission | Owner | Group | Other | Octal |
|---|---|---|---|---|
| `-rw----r--` | r+w = 6 | 0 | r = 4 | **604** |
| `drwxr-xr-x` | r+w+x = 7 | r+x = 5 | r+x = 5 | **755** |
| `-rwxrwxrwx` | 7 | 7 | 7 | **777** |

Permissions are referred to in octal notation from here on.

## Changing Permissions

Permissions can be modified through several methods:

- **FTP client**: See [[accessing-ftp-server]] for details
- **Control panel**: **Files** > **File Manager** > **Properties** action
- **Terminal**: Use the [chmod](http://apnscp.com/linux-man/man1/chmod.1.html) command via [[accessing-terminal]]

Permissions can be applied to a single file or recursively to all files and directories within a directory. Files created after the change will not inherit the new permissions.

## Understanding 777 vs 717

Permission `777` grants full read/write/execute access to all users. While commonly recommended for PHP applications, it also allows every user on your account to modify and delete those files.

**Use `717` instead of `777`**: this grants full access to the owner and other (which includes the web server), while locking out group members (other users on your account). PHP applications will still function correctly with `717` permissions.

## Why Use Multiple Users?

Using separate user accounts for different purposes limits the damage from a security breach:

- Brute-force attacks against FTP passwords are common and sophisticated, using botnets of hundreds of thousands of machines
- A single botnet can test over 1,200,000 password combinations per day -- enough to exhaust every 4-character lowercase alphanumeric password in a single day
- Outdated web applications are another common attack vector

**Best practices:**

1. Use separate users to isolate the impact of unauthorized access
2. Apply permissions only to files that genuinely need broader access
3. Keep web applications updated

## See Also

- [[writing-to-files]]
