dotlinux guide

Understanding Linux File Permissions: How to Read, Use, and Secure Your System

Introduction

Linux, as a multi-user operating system, relies on a robust permission system to control access to files and directories. This system ensures that users and processes can only interact with files in authorized ways, safeguarding sensitive data and maintaining system stability. Whether you’re a developer, system administrator, or casual user, understanding Linux file permissions is critical for tasks like securing data, troubleshooting access issues, and collaborating in shared environments.

In this guide, we’ll demystify Linux file permissions, starting with how to read them, breaking down their components, and exploring how to modify and manage them effectively. By the end, you’ll be equipped to handle common permission scenarios and follow best practices to keep your system secure.

What Are Linux File Permissions?

File permissions in Linux define who can read, write, or execute (run) a file or directory. They are enforced for three distinct user classes:

  • Owner: The user who created the file (or was assigned ownership).
  • Group: A collection of users with shared access rights to the file.
  • Others: All users not in the owner or group classes (i.e., the rest of the system).

Permissions act as a gatekeeper, ensuring that only authorized users can modify critical system files, access sensitive data, or run executable programs.

How to Read File Permissions

To view file permissions, use the ls -l command (short for “list in long format”). This displays a detailed breakdown of each file’s metadata, including permissions, owner, group, size, and modification time. Here’s an example output for a file and directory:

ls -l /home/user/documents

Sample output:

-rw-r--r--@ user staff /home/user/documents/report.pdf
drwxr-xr-x  user team  /home/user/documents/projects/ directory)

Let’s dissect the permission string (the first column in the output) to understand its structure.

The Permission String

The permission string is 10 characters long, structured as follows:

[File Type][Owner Permissions][Group Permissions][Others Permissions]

Example Breakdown: -rw-r--r--

  • 1st character: File type (- for a regular file, d for a directory, etc.).
  • 2-4th characters: Permissions for the owner (rw- = read and write, no execute).
  • 5-7th characters: Permissions for the group (r-- = read only).
  • 8-10th characters: Permissions for others (r-- = read only).

File Types

The first character of the permission string indicates the file type. Common types include:

CharacterFile TypeDescription
-Regular fileText files, binaries, scripts, etc. (most common).
dDirectoryA folder containing other files/directories.
lSymbolic linkA shortcut to another file/directory (points to a target path).
bBlock deviceHardware like hard drives (e.g., /dev/sda).
cCharacter deviceHardware like keyboards or terminals (e.g., /dev/tty).
pPipeA temporary channel for inter-process communication (e.g., mkfifo pipe).
sSocketA network communication endpoint (e.g., /run/docker.sock).

Permission Sets: User, Group, Others

The next 9 characters (split into three groups of 3) represent permissions for the owner, group, and others. Each group contains three possible permissions:

CharacterPermissionDescription
rReadAllows viewing the file’s content (for files) or listing directory contents (for directories).
wWriteAllows modifying the file (for files) or adding/removing files (for directories).
xExecuteAllows running the file (for executable files/scripts) or accessing the directory (e.g., cd).
-No permissionThe permission is not granted.

What Do r, w, x Mean for Files vs. Directories?

Permissions behave differently for files and directories. Understanding this distinction is critical for troubleshooting access issues.

For Regular Files:

  • r (Read): View or copy the file’s content (e.g., cat file.txt, cp file.txt backup.txt).
  • w (Write): Modify, delete, or rename the file (e.g., nano file.txt, rm file.txt).
  • x (Execute): Run the file as a program or script (e.g., ./script.sh, /bin/ls).

For Directories:

  • r (Read): List the directory’s contents (e.g., ls /home/user).
  • w (Write): Add, delete, or rename files/directories within it (e.g., touch newfile.txt, rm oldfile.txt).
  • x (Execute): Access the directory (e.g., cd /home/user) or interact with files inside it (even if you don’t have r permission, you can access files by name if you know them).

Permission Notation: Symbolic vs. Numeric

Permissions can be represented in two formats: symbolic (human-readable letters) and numeric (octal) (digits for quick modification).

Symbolic Notation

Symbolic notation uses letters to describe permissions, making it intuitive for incremental changes. It follows this format:

[User Class][Operator][Permission]  
  • User Classes: u (owner), g (group), o (others), a (all users, i.e., u+g+o).
  • Operators: + (add permission), - (remove permission), = (set exact permissions).
  • Permissions: r, w, x.

Examples:

  • u+x: Add execute permission for the owner.
  • g-w: Remove write permission for the group.
  • o=r: Set others’ permissions to read-only.
  • a+rwx: Add read, write, and execute for all users (use with caution!).

Numeric (Octal) Notation

Numeric notation uses a 3-digit octal number (0-7) to represent permissions for the owner, group, and others. Each digit is the sum of values assigned to r, w, and x:

PermissionValue
r4
w2
x1
-0

Example Conversions:

  • rw- (read + write) = 4 + 2 + 0 = 6.
  • r-x (read + execute) = 4 + 0 + 1 = 5.
  • rwx (read + write + execute) = 4 + 2 + 1 = 7.

Thus, the permission string -rw-r--r-- translates to:

  • Owner: rw- = 6
  • Group: r-- = 4
  • Others: r-- = 4
  • Numeric notation: 644.

Changing Permissions with chmod

The chmod command (short for “change mode”) modifies file permissions. It supports both symbolic and numeric notation.

Symbolic Mode Examples

Add execute permission for the owner of a script:

chmod u+x script.sh  

Remove write permission for others from a sensitive file:

chmod o-w secret.txt  

Set group permissions to read/execute (overriding existing group permissions):

chmod g=rx project/  

Add read permission for all users (owner, group, others):

chmod a+r notes.txt  

Numeric Mode Examples

Set a file to rw-r--r-- (owner read/write, group/others read-only):

chmod 644 report.pdf  

Set a directory to rwxr-xr-x (owner read/write/execute, group/others read/execute):

chmod 755 projects/  

Make a script executable for the owner only (rwx------):

chmod 700 install.sh  

Special Permissions: SUID, SGID, and Sticky Bit

Beyond the standard rwx permissions, Linux supports three special permission bits: SUID, SGID, and Sticky Bit. These modify how files/directories behave when accessed.

SUID (Set User ID)

  • Purpose: When a file with SUID is executed, it runs with the permissions of the file’s owner, not the user who ran it.
  • Use Case: Critical for programs like passwd (which modifies /etc/shadow, a file only root can write to).
  • Notation: Replaces the x in the owner’s permission set with s (e.g., -rwsr-xr-x). If the owner has no x permission, it shows as S (uppercase).

Example: Set SUID on a file:

chmod u+s /usr/bin/myprogram  # Symbolic  
chmod 4755 /usr/bin/myprogram  # Numeric (4 = SUID, 755 = rwxr-xr-x)  

SGID (Set Group ID)

  • Purpose: For files: Runs the file with the permissions of the file’s group. For directories: New files created in the directory inherit the directory’s group (instead of the user’s default group).
  • Use Case: Shared project directories where all team members should own files under a common group.
  • Notation: Replaces the x in the group’s permission set with s (e.g., drwxr-sr-x).

Example: Set SGID on a shared directory:

chmod g+s team_projects/  # Symbolic  
chmod 2775 team_projects/  # Numeric (2 = SGID, 775 = rwxrwxr-x)  

Sticky Bit

  • Purpose: On directories, only the owner of a file (or root) can delete it, even if others have write permission to the directory.
  • Use Case: Shared temporary directories like /tmp, where users should create files but not delete others’ files.
  • Notation: Replaces the x in the others’ permission set with t (e.g., drwxrwxrwt).

Example: Set the sticky bit on a shared directory:

chmod o+t shared_files/  # Symbolic  
chmod 1777 shared_files/  # Numeric (1 = Sticky Bit, 777 = rwxrwxrwx)  

Common Practices

Here are common permission patterns for everyday use:

ScenarioPermissionNumericDescription
Regular files (documents)rw-r--r--644Owner read/write, group/others read-only (safe for most files).
Directoriesrwxr-xr-x755Owner full access, group/others read/execute (standard for public dirs).
Executable scriptsrwxr-xr-x755Owner/group/others can run the script.
Sensitive files (e.g., SSH keys)rw-------600Only the owner can read/write (prevents unauthorized access).
Shared project directoriesrwxrwsr-x2775SGID ensures new files inherit the group; group members can modify files.

Best Practices for Security and Efficiency

To keep your system secure and avoid permission-related issues:

  1. Follow the Principle of Least Privilege:
    Only grant the minimum permissions required. For example, avoid 777 (world-writable) unless absolutely necessary (e.g., /tmp with sticky bit).

  2. Audit Permissions Regularly:
    Use tools like find to locate overly permissive files/directories:

    find /home -type f -perm 777  # Find world-writable files in /home  
    find /var -type d -perm -o+w  # Find directories writable by others  
  3. Use Groups for Collaboration:
    Instead of modifying permissions for “others,” create a shared group and add users to it. Use SGID on directories to ensure new files inherit the group.

  4. Avoid Overusing SUID/SGID:
    These bits can introduce security risks (e.g., a malicious user could exploit a SUID binary to gain elevated privileges). Only use them for trusted programs.

  5. Backup Before Bulk Changes:
    When modifying permissions recursively (e.g., chmod -R 755 /path), back up data first to avoid accidental data loss.

  6. Leverage stat for Details:
    Use stat filename to view extended permission info (e.g., SUID/SGID bits, inode details).

Conclusion

Linux file permissions are a cornerstone of system security and access control. By mastering how to read permission strings, modify permissions with chmod, and use special bits like SUID/SGID, you can ensure data integrity, troubleshoot access issues, and collaborate safely in multi-user environments.

Remember: permissions are not just about restricting access—they’re about enabling authorized users to work efficiently while keeping your system protected. Start with the basics, practice with ls -l and chmod, and always follow the principle of least privilege.

References