Linux File Permissions & Ownership Explained: Complete Guide for Beginners

# Linux File Permissions & Ownership Explained: Complete Guide for Beginners

Linux permissions are the foundation of system security, controlling who can read, write, or execute files and directories. Understanding **linux permissions** is critical for penetration testers, system administrators, and anyone working with Kali Linux. This comprehensive guide will teach you everything from basic permission concepts to advanced security implications.

## Table of Contents

1. [Understanding the Linux Permission Model](#understanding-the-linux-permission-model)
2. [Viewing File Permissions](#viewing-file-permissions)
3. [Numeric Permission Notation](#numeric-permission-notation)
4. [Symbolic Permission Notation](#symbolic-permission-notation)
5. [The chmod Command](#the-chmod-command)
6. [Ownership: chown and chgrp](#ownership-chown-and-chgrp)
7. [Special Permissions Explained](#special-permissions-explained)
8. [Understanding umask](#understanding-umask)
9. [Permission Security Implications for Pentesters](#permission-security-implications-for-pentesters)
10. [Practical Exercises](#practical-exercises)
11. [Frequently Asked Questions](#frequently-asked-questions)

---

## Understanding the Linux Permission Model

Linux implements a **discretionary access control** (DAC) system where every file and directory has an owner, a group, and three sets of permissions that apply to:

### The Three Permission Classes

1. **Owner (User)** - The user who owns the file
2. **Group** - Users who belong to the file's group
3. **Others (World)** - All other users on the system

### The Three Permission Types

Each class can have three types of permissions:

| Permission | Symbol | Value | For Files | For Directories |
|------------|--------|-------|-----------|----------------|
| **Read** | r | 4 | View file contents | List directory contents |
| **Write** | w | 2 | Modify file contents | Create/delete files in directory |
| **Execute** | x | 1 | Run file as program | Enter directory with cd |

**Key Concept:** Directory execute permission is required to access (cd into) a directory, while read permission lets you list its contents.

### Real-World Example

Imagine a file called `script.sh`:

- **Owner** (you): Read, write, execute (you can read, modify, and run it)
- **Group** (developers team): Read, execute (team members can read and run it, but not modify)
- **Others** (everyone else): No permissions (random users can't access it at all)

This granular control is essential for multi-user systems and critical for security in [penetration testing environments](/articles/pentest-methodology-the-complete-guide-for-2026).

---

## Viewing File Permissions

The `ls -l` command displays detailed file information including permissions:

```bash
ls -l /home/kali/script.sh
```

**Output:**
```
-rwxr-xr-- 1 kali kali 1234 Jan 15 10:30 script.sh
```

Let's break down this output:

```
-rwxr-xr-- 1 kali kali 1234 Jan 15 10:30 script.sh
│││││││││└ ─ User (Owner) │ │ │ │ │
││││││││└─── Group │ │ │ │ │
│││││││└──── Permissions │ │ │ │ │
││││││└───── (Others) │ │ │ │ │
│││││└────── (Group) │ │ │ │ │
││││└─────── (User) │ │ │ │ │
│││└──────── File type │ │ │ │ │
││└───────── Links │ │ │ │ Filename
│└────────── Owner │ │ │ Modification time
└─────────── Size in bytes │ │ Day
│ Month
Hard link count
```

### Breaking Down the Permission String

**`-rwxr-xr--`** breaks into four parts:

1. **File type** (`-`):
- `-` = regular file
- `d` = directory
- `l` = symbolic link
- `b` = block device
- `c` = character device

2. **Owner permissions** (`rwx`): Read, write, execute
3. **Group permissions** (`r-x`): Read, no write, execute
4. **Others permissions** (`r--`): Read only

### Quick Permission Check Commands

```bash
# View permissions for current directory
ls -l

# View permissions including hidden files
ls -la

# View directory permissions (not contents)
ls -ld /etc

# View permissions in human-readable format with sizes
ls -lh

# View with numeric user/group IDs
ls -ln
```

Pro tip: Combine with `stat` for even more detail:

```bash
stat script.sh
```

This shows permissions in both symbolic and numeric (octal) format, along with inode, timestamps, and more.

---

## Numeric Permission Notation (Octal)

Numeric notation uses **octal numbers** (base 8: 0-7) to represent permissions. Each permission type has a value:

- **Read (r)** = 4
- **Write (w)** = 2
- **Execute (x)** = 1
- **No permission (-)** = 0

Three digits represent owner, group, and others permissions.

### Common Permission Values

| Numeric | Symbolic | Meaning | Typical Use |
|---------|----------|---------|-------------|
| **777** | rwxrwxrwx | Full permissions for everyone | **DANGEROUS** - Never use in production |
| **755** | rwxr-xr-x | Owner full, others read/execute | Executable scripts, binaries |
| **700** | rwx------ | Owner full, no access for others | Private directories |
| **644** | rw-r--r-- | Owner read/write, others read-only | Regular files, documents |
| **600** | rw------- | Owner read/write only | Private files, SSH keys |
| **555** | r-xr-xr-x | Read/execute for all, no write | System binaries |
| **444** | r--r--r-- | Read-only for everyone | Immutable reference files |
| **000** | --------- | No permissions | Completely locked files |

### Calculating Numeric Permissions

To calculate permissions, **add the values** for each class:

**Example: rwxr-x---**

- **Owner:** r(4) + w(2) + x(1) = **7**
- **Group:** r(4) + x(1) = **5**
- **Others:** 0 = **0**
- **Result:** **750**

**Example: rw-rw-r--**

- **Owner:** r(4) + w(2) = **6**
- **Group:** r(4) + w(2) = **6**
- **Others:** r(4) = **4**
- **Result:** **664**

### Quick Reference Table

| Sum | Permission |
|-----|------------|
| 0 | `---` (no access) |
| 1 | `--x` (execute) |
| 2 | `-w-` (write) |
| 3 | `-wx` (write + execute) |
| 4 | `r--` (read) |
| 5 | `r-x` (read + execute) |
| 6 | `rw-` (read + write) |
| 7 | `rwx` (full access) |

---

## Symbolic Permission Notation

Symbolic notation uses **letters and operators** to modify permissions. This method is more intuitive when you want to add or remove specific permissions without calculating octal values.

### Symbolic Components

**Who (user classes):**
- `u` = user (owner)
- `g` = group
- `o` = others
- `a` = all (ugo combined)

**Operators:**
- `+` = add permission
- `-` = remove permission
- `=` = set exact permission (overwrites existing)

**Permissions:**
- `r` = read
- `w` = write
- `x` = execute

### Symbolic Notation Examples

| Symbolic | Meaning |
|----------|----------|
| `u+x` | Add execute permission for owner |
| `g-w` | Remove write permission from group |
| `o=r` | Set others to read-only (removes write/execute) |
| `a+r` | Add read permission for all |
| `ug+rw` | Add read/write for owner and group |
| `o-rwx` | Remove all permissions from others |
| `u=rwx,g=rx,o=` | Set owner=rwx, group=rx, others=none |

**Multiple changes** can be combined with commas:

```bash
chmod u+x,g-w,o=r file.txt
```

This adds execute for owner, removes write from group, and sets others to read-only.

---

## The chmod Command

`chmod` (change mode) modifies file and directory permissions. You can use it with either numeric or symbolic notation.

### Basic chmod Syntax

```bash
chmod [options] mode file
```

### Using Numeric Mode

```bash
# Make a script executable for owner only
chmod 700 script.sh

# Standard file permissions (owner rw, others r)
chmod 644 document.txt

# Standard directory permissions (owner rwx, others rx)
chmod 755 /var/www/html

# Private SSH key (owner read/write only)
chmod 600 ~/.ssh/id_rsa

# World-writable (DANGEROUS!)
chmod 777 file.txt # Never do this in production!
```

### Using Symbolic Mode

```bash
# Add execute permission for owner
chmod u+x script.sh

# Remove write permission from group and others
chmod go-w file.txt

# Add read permission for everyone
chmod a+r document.txt

# Set exact permissions: owner rwx, group rx, others nothing
chmod u=rwx,g=rx,o= script.sh

# Make file read-only for everyone
chmod a-w,a+r file.txt
```

### Recursive Permission Changes

The `-R` flag applies changes recursively to directories and their contents:

```bash
# Change all files and subdirectories
chmod -R 755 /var/www/html

# Add execute to all subdirectories only (capital X)
chmod -R u+X /home/kali/scripts
```

**Important:** Capital `X` adds execute only to directories and files that already have execute permission for someone. This prevents making text files executable.

### Preserving Root Directory Permissions

```bash
# Apply to directory contents, not the directory itself
chmod 644 /etc/nginx/*

# Better approach: change directory, then contents
cd /etc/nginx && chmod 644 *
```

### Common chmod Use Cases in Kali Linux

```bash
# Make exploit script executable
chmod +x exploit.py

# Secure SSH private key
chmod 600 ~/.ssh/id_rsa

# Set up shared directory for team
chmod 770 /home/shared

# Make web files readable
chmod 644 /var/www/html/*.html

# Secure sensitive config files
chmod 640 /etc/nginx/nginx.conf
```

---

## Ownership: chown and chgrp

File **ownership** determines who has ultimate control over a file and which group it belongs to. Ownership is set when a file is created, but can be changed with `chown` and `chgrp`.

### Understanding Ownership

Every file has two ownership attributes:
1. **User owner** - The user account that owns the file
2. **Group owner** - The group that owns the file

You can view ownership with:

```bash
ls -l file.txt
# -rw-r--r-- 1 kali developers 1234 Jan 15 10:30 file.txt
# │ │
# │ └─ Group owner
# └────── User owner
```

### The chown Command

`chown` (change owner) modifies user and group ownership.

**Basic Syntax:**
```bash
chown [options] user[:group] file
```

**Examples:**

```bash
# Change owner to 'john'
sudo chown john file.txt

# Change owner and group
sudo chown john:developers file.txt

# Change owner only, keep existing group
sudo chown john: file.txt

# Change group only (see also chgrp)
sudo chown :developers file.txt

# Recursive ownership change
sudo chown -R kali:kali /home/kali/projects

# Change owner based on another file's ownership
sudo chown --reference=original.txt copy.txt
```

**Important:** Only root (or sudo) can change file ownership. You cannot give away ownership of your files to another user without root privileges.

### The chgrp Command

`chgrp` (change group) changes only the group ownership:

```bash
# Change group to 'developers'
chgrp developers file.txt

# Recursive group change
chgrp -R www-data /var/www/html

# Change group based on another file
chgrp --reference=template.txt *.txt
```

**Note:** You can only change a file's group to a group you belong to (or use sudo).

### Practical Ownership Scenarios

**Setting up a web server:**
```bash
# Make nginx own web files
sudo chown -R www-data:www-data /var/www/html
sudo chmod -R 755 /var/www/html
```

**Creating a shared project directory:**
```bash
# Create shared directory
sudo mkdir /home/shared
sudo chown root:developers /home/shared
sudo chmod 770 /home/shared
```

**Fixing ownership after sudo operations:**
```bash
# You accidentally created files as root, fix it:
sudo chown -R kali:kali /home/kali/documents
```

---

## Special Permissions Explained

Beyond standard read, write, execute permissions, Linux has **three special permission bits** that change how executables and directories behave:

1. **SUID (Set User ID)**
2. **SGID (Set Group ID)**
3. **Sticky Bit**

These are critical for penetration testers to understand, as **SUID/SGID binaries are common privilege escalation vectors**.

### SUID (Set User ID) - Permission Bit 4000

**What it does:** When a file with SUID is executed, it runs with the **permissions of the file's owner**, not the user who ran it.

**Symbol:** `s` in owner's execute position (`rws` or `rwS`)
- Lowercase `s` = SUID + execute
- Uppercase `S` = SUID without execute (rarely useful)

**Example:**

```bash
ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 Jul 14 2021 /usr/bin/passwd
```

The `passwd` command has SUID. When you run it, it executes with **root privileges** (because the owner is root), allowing you to modify `/etc/shadow` even though you don't normally have access.

**Setting SUID:**

```bash
# Numeric notation (4 prefix)
sudo chmod 4755 /usr/local/bin/myapp

# Symbolic notation
sudo chmod u+s /usr/local/bin/myapp
```

**Security Warning:** SUID binaries are dangerous if misconfigured. A vulnerable SUID root binary can lead to full system compromise.

### SGID (Set Group ID) - Permission Bit 2000

**On executable files:** Runs with **group** permissions of the file's group owner.

**On directories:** Files created inside inherit the **directory's group** instead of the creator's default group.

**Symbol:** `s` in group's execute position (`rwxr-s`)

**Example - SGID Executable:**

```bash
ls -l /usr/bin/wall
-rwxr-sr-x 1 root tty 23432 Jan 18 2021 /usr/bin/wall
```

**Example - SGID Directory:**

```bash
mkdir /home/shared
sudo chgrp developers /home/shared
sudo chmod 2775 /home/shared
ls -ld /home/shared
drwxrwsr-x 2 root developers 4096 Jan 15 10:30 /home/shared
```

Now any file created in `/home/shared` will have group `developers`, enabling team collaboration.

**Setting SGID:**

```bash
# Numeric notation (2 prefix)
chmod 2755 shared_directory

# Symbolic notation
chmod g+s shared_directory
```

### Sticky Bit - Permission Bit 1000

**What it does:** On directories, only the **file owner, directory owner, or root** can delete or rename files inside, even if others have write permission.

**Symbol:** `t` in others' execute position (`rwxrwxrwt`)
- Lowercase `t` = sticky bit + execute
- Uppercase `T` = sticky bit without execute

**Example:**

```bash
ls -ld /tmp
drwxrwxrwt 12 root root 4096 Jan 15 10:45 /tmp
```

The `/tmp` directory has the sticky bit. Anyone can create files there (world-writable), but users can only delete their own files.

**Setting Sticky Bit:**

```bash
# Numeric notation (1 prefix)
chmod 1777 /tmp

# Symbolic notation
chmod +t /tmp
```

**Use case:** Shared directories where multiple users can create files but shouldn't be able to delete each other's work.

### Special Permissions Summary Table

| Permission | Numeric | Symbolic | File Effect | Directory Effect |
|------------|---------|----------|-------------|------------------|
| **SUID** | 4000 | `u+s` | Execute as file owner | No effect |
| **SGID** | 2000 | `g+s` | Execute as file's group | New files inherit directory group |
| **Sticky** | 1000 | `+t` | No effect | Only owner can delete files |

### Combining Special and Standard Permissions

```bash
# SUID + 755 = 4755
chmod 4755 binary # rwsr-xr-x

# SGID + 775 = 2775
chmod 2775 directory # rwxrwsr-x

# Sticky + 777 = 1777
chmod 1777 /tmp # rwxrwxrwt

# All three special bits + 755 = 7755
chmod 7755 file # rwsrwsrwt (rarely used)
```

---

## Understanding umask

`umask` (user file creation mask) determines the **default permissions** for newly created files and directories by *subtracting* permissions from the system maximum.

### Default Maximum Permissions

- **Files:** 666 (rw-rw-rw-)
- **Directories:** 777 (rwxrwxrwx)

The umask **removes** permissions from these defaults.

### How umask Works

If your umask is `0022`:

**For files:**
```
Maximum: 666 (rw-rw-rw-)
umask: -022 (----w--w-)
Result: 644 (rw-r--r--)
```

**For directories:**
```
Maximum: 777 (rwxrwxrwx)
umask: -022 (----w--w-)
Result: 755 (rwxr-xr-x)
```

### Viewing and Setting umask

```bash
# View current umask (numeric)
umask
0022

# View current umask (symbolic)
umask -S
u=rwx,g=rx,o=rx

# Set umask for current session
umask 0027

# Test: create a file and check its permissions
touch testfile
ls -l testfile
-rw-r----- 1 kali kali 0 Jan 15 11:00 testfile
```

### Common umask Values

| umask | Files | Directories | Use Case |
|-------|-------|-------------|----------|
| **0022** | 644 | 755 | Default for most users - group/others can read |
| **0027** | 640 | 750 | More restrictive - only group can read |
| **0077** | 600 | 700 | Paranoid - only owner has any access |
| **0002** | 664 | 775 | Group-friendly - group has write access |
| **0000** | 666 | 777 | No restrictions (DANGEROUS) |

### Making umask Permanent

Add to your shell configuration file:

```bash
# For bash
echo "umask 0027" >> ~/.bashrc

# For zsh
echo "umask 0027" >> ~/.zshrc

# System-wide (all users)
sudo echo "umask 0027" >> /etc/profile
```

### Security Consideration

After [setting up Kali Linux](/tutorials/kali-linux-setup-essential-post-installation-steps-2026), consider setting a restrictive umask (0027 or 0077) to prevent accidentally creating world-readable sensitive files.

---

## Permission Security Implications for Pentesters

As a penetration tester, understanding Linux permissions is crucial for **privilege escalation**, **lateral movement**, and **persistence**. Here are key security concepts:

### 1. Finding SUID/SGID Binaries

SUID/SGID binaries running as root are prime privilege escalation targets:

```bash
# Find all SUID binaries
find / -perm -4000 -type f 2>/dev/null

# Find all SGID binaries
find / -perm -2000 -type f 2>/dev/null

# Find both SUID and SGID
find / -perm -6000 -type f 2>/dev/null

# More detailed listing
find / -perm -4000 -type f -exec ls -la {} \; 2>/dev/null
```

**What to look for:**
- Custom SUID binaries (not standard system binaries)
- Unusual paths (`/tmp`, user home directories)
- Binaries vulnerable to path hijacking or buffer overflows

**Example exploitation:**
If you find a custom SUID binary that calls `system()` with relative paths:

```bash
# Found: /usr/local/bin/vulnerable_suid_binary
# It calls system("cat /tmp/log.txt")

# Exploit: hijack the PATH
cd /tmp
echo '#!/bin/bash' > cat
echo 'bash -i' >> cat
chmod +x cat
PATH=/tmp:$PATH /usr/local/bin/vulnerable_suid_binary
# Now you have a root shell!
```

### 2. World-Writable Directories and Files

World-writable locations are opportunities for **privilege escalation** and **persistence**:

```bash
# Find world-writable directories
find / -type d -perm -0002 2>/dev/null | grep -v proc

# Find world-writable files
find / -type f -perm -0002 2>/dev/null

# Find world-writable files owned by root
find / -type f -perm -0002 -user root 2>/dev/null
```

**Exploitation scenarios:**
- **Cron jobs**: If a root cron script is in a world-writable directory, modify it
- **Shared libraries**: Inject malicious code into writable libraries
- **Config files**: Modify startup scripts or service configurations

### 3. Readable Sensitive Files

Look for files that should be restricted but aren't:

```bash
# Check shadow file (should be 000 or 640)
ls -l /etc/shadow

# Find readable password files
find /etc -name "*password*" -type f 2>/dev/null
find /var -name "*password*" -type f 2>/dev/null

# Check SSH private keys with weak permissions
find / -name "id_rsa" -or -name "id_dsa" 2>/dev/null | xargs ls -l

# Find config files with passwords
grep -r "password=" /etc 2>/dev/null
grep -r "PASSWORD=" /opt 2>/dev/null
```

### 4. Group-Based Privilege Escalation

Check group memberships for privilege escalation opportunities:

```bash
# View your groups
groups
id

# Find files writable by your groups
find / -group $(id -gn) -writable 2>/dev/null

# Dangerous groups:
# - sudo: can run sudo commands
# - docker: can spawn root shell via containers
# - disk: direct disk access
# - lxd: container-based privilege escalation
```

**Docker group privilege escalation:**

```bash
# If you're in the docker group:
docker run -v /:/hostfs -it ubuntu bash
cd /hostfs/root
# Now you have root filesystem access!
```

### 5. Sticky Bit Bypass

The sticky bit prevents users from deleting others' files, but vulnerabilities exist:

```bash
# Check if /tmp has sticky bit
ls -ld /tmp

# If /tmp doesn't have sticky bit (vulnerable):
# Any user can delete any file in /tmp
# Can lead to DoS or race condition exploits
```

### 6. Capability-Based Execution

Linux capabilities provide fine-grained privileges without full SUID:

```bash
# Find binaries with capabilities
getcap -r / 2>/dev/null

# Common dangerous capabilities:
# cap_setuid - change UID (privilege escalation)
# cap_dac_read_search - bypass file read restrictions
# cap_sys_admin - mount filesystems, etc.
```

**Example exploitation (cap_setuid):**

```bash
# If you find: /usr/bin/python3 = cap_setuid+ep
python3 -c 'import os; os.setuid(0); os.system("/bin/bash")'
# Root shell!
```

### 7. Security Checklist for Pentesters

**During enumeration on a compromised system:**

- [ ] Find SUID/SGID binaries (`find / -perm -4000`)
- [ ] Search for world-writable files and directories
- [ ] Check group memberships (`id`, `groups`)
- [ ] Look for capabilities (`getcap -r /`)
- [ ] Read cron jobs and check their file permissions
- [ ] Enumerate writable directories in PATH
- [ ] Check for weak SSH key permissions
- [ ] Review sudoers file (`sudo -l`)
- [ ] Search for password files with weak permissions
- [ ] Test for NFS shares with no_root_squash

These checks align with professional [penetration testing methodology](/articles/pentest-methodology-the-complete-guide-for-2026).

---

## Practical Exercises

Reinforce your understanding with these hands-on exercises in your [Kali Linux virtual machine](/tutorials/how-to-install-kali-linux-in-virtualbox-complete-2026-guide):

### Exercise 1: Permission Basics

```bash
# Create a test directory
mkdir ~/perms_practice
cd ~/perms_practice

# Create three files
touch file1.txt file2.txt script.sh

# Tasks:
# 1. Set file1.txt to 644 (owner rw, others r)
chmod 644 file1.txt

# 2. Set file2.txt to 600 (owner rw only)
chmod 600 file2.txt

# 3. Make script.sh executable for owner only (700)
chmod 700 script.sh

# 4. Verify with ls -l
ls -l

# 5. Remove write permission from file1.txt for everyone
chmod a-w file1.txt

# 6. Try to edit file1.txt - should fail
echo "test" > file1.txt # Permission denied
```

### Exercise 2: Symbolic vs Numeric Notation

```bash
# Create a file
touch test.txt

# Set permissions using numeric notation
chmod 754 test.txt
ls -l test.txt
# -rwxr-xr-- 1 kali kali 0 Jan 15 12:00 test.txt

# Now achieve the same result using symbolic notation
chmod u=rwx,g=rx,o=r test.txt
ls -l test.txt
# Same result!

# Add execute for group
chmod g+x test.txt

# Remove read for others
chmod o-r test.txt

# What's the current numeric value? Check with stat
stat test.txt
```

### Exercise 3: Ownership Changes

```bash
# Create a file and check ownership
touch myfile.txt
ls -l myfile.txt
# -rw-r--r-- 1 kali kali 0 Jan 15 12:00 myfile.txt

# Create a test group (you'll need sudo)
sudo groupadd testgroup

# Add yourself to the group
sudo usermod -aG testgroup kali

# Log out and back in for group changes to take effect
# Or run: newgrp testgroup

# Change group ownership
chgrp testgroup myfile.txt
ls -l myfile.txt

# Try to change owner to root (will fail without sudo)
chown root myfile.txt # Operation not permitted

# Now with sudo
sudo chown root myfile.txt
ls -l myfile.txt
```

### Exercise 4: Special Permissions

```bash
# Create a shared directory with SGID
mkdir ~/shared_project
chmod 2775 ~/shared_project
ls -ld ~/shared_project
# drwxrwsr-x 2 kali kali 4096 Jan 15 12:00 shared_project

# Create a file inside
touch ~/shared_project/newfile.txt

# Notice the group is inherited from the directory
ls -l ~/shared_project/newfile.txt

# Create a directory with sticky bit
mkdir ~/temp_shared
chmod 1777 ~/temp_shared
ls -ld ~/temp_shared
# drwxrwxrwt 2 kali kali 4096 Jan 15 12:00 temp_shared

# Simulate SUID (requires a compiled binary)
cat > setuid_test.c << 'EOF'
#include <stdio.h>
#include <unistd.h>
int main() {
printf("My UID: %d\\n", getuid());
printf("Effective UID: %d\\n", geteuid());
return 0;
}
EOF

gcc setuid_test.c -o setuid_test
chmod u+s setuid_test
ls -l setuid_test
# -rwsr-xr-x 1 kali kali 16000 Jan 15 12:00 setuid_test

./setuid_test
# Shows real UID and effective UID
```

### Exercise 5: Security Enumeration

```bash
# Create a vulnerable scenario
mkdir ~/security_test
cd ~/security_test

# Create a world-writable file
touch vulnerable.txt
chmod 666 vulnerable.txt

# Create a script with SUID (simulate)
touch fake_suid.sh
chmod 4755 fake_suid.sh

# Now practice your enumeration:

# Find SUID files in current directory
find . -perm -4000 -type f 2>/dev/null

# Find world-writable files
find . -perm -0002 -type f 2>/dev/null

# Check umask
umask

# Create a file and observe default permissions
touch default_perms.txt
ls -l default_perms.txt

# Change umask and retry
umask 0077
touch restrictive_perms.txt
ls -l restrictive_perms.txt
# Should be -rw-------
```

### Exercise 6: Real-World Web Server Setup

Simulate setting up proper permissions for a web server (requires sudo):

```bash
# Create a mock web directory
sudo mkdir -p /var/www/html/testsite
cd /var/www/html/testsite

# Create some files
sudo touch index.html style.css script.js

# Set proper ownership (web server user is usually www-data or nginx)
sudo chown -R www-data:www-data /var/www/html/testsite

# Set proper permissions:
# Directories: 755 (rwxr-xr-x)
# Files: 644 (rw-r--r--)
sudo find /var/www/html/testsite -type d -exec chmod 755 {} \;
sudo find /var/www/html/testsite -type f -exec chmod 644 {} \;

# Verify
ls -la /var/www/html/testsite

# Create an upload directory (needs write permission for web server)
sudo mkdir /var/www/html/testsite/uploads
sudo chown www-data:www-data /var/www/html/testsite/uploads
sudo chmod 775 /var/www/html/testsite/uploads

# Verify the setup
ls -ld /var/www/html/testsite/uploads
```

**Best practices demonstrated:**
- Web files owned by web server user
- Files are readable but not writable by web server (security)
- Upload directories have write permission but are carefully monitored
- Directories have execute permission (required to enter)

---

## Frequently Asked Questions

### 1. What's the difference between chmod 777 and chmod +x?

**chmod 777** sets **absolute permissions** to `rwxrwxrwx` - full read, write, execute for owner, group, and others. This is extremely dangerous and should **never** be used in production.

**chmod +x** (or `chmod a+x`) **adds** execute permission to existing permissions without changing read or write. For example:
- If a file is `rw-r--r--` (644), `chmod +x` makes it `rwxr-xr-x` (755)
- If a file is `rw-------` (600), `chmod +x` makes it `rwx------` (700)

**Best practice:** Use `chmod +x` for scripts. Only use numeric notation when you need precise control.

### 2. Why can't I delete a file even with write permission on it?

To delete a file, you need **write permission on the parent directory**, not the file itself.

Example:
```bash
# You have a file you own
touch /tmp/myfile.txt
chmod 644 /tmp/myfile.txt # You have read/write

# But if /tmp didn't allow you to write:
sudo chmod 555 /tmp # Now /tmp is r-xr-xr-x
rm /tmp/myfile.txt # This will FAIL
# Because deletion modifies the directory, not the file
```

This is why shared directories often have:
- **Sticky bit**: Users can't delete each other's files
- **775 or 777**: Users can create and delete files

### 3. What's the difference between SUID and sudo?

Both allow regular users to run commands with elevated privileges, but they work differently:

**SUID:**
- **Permanent** bit set on an executable file
- **Always** runs as the file owner (often root)
- User has **no control** over which commands run with privilege
- Example: `/usr/bin/passwd` always runs as root

**sudo:**
- **Configuration-based** permission system (`/etc/sudoers`)
- User explicitly requests elevated privileges
- **Granular control**: can allow specific commands only
- Requires user's password (authentication)
- Logged in audit trail

**Security:**
- SUID is more dangerous if the binary has vulnerabilities
- sudo provides better accountability and control
- Modern systems prefer sudo with capability-based security

After [setting up user management in Kali](/tutorials/kali-linux-default-password-user-management-guide-for-beginners-2026), configure sudo instead of relying on SUID binaries.

### 4. How do I find files modified in the last 24 hours with specific permissions?

Combine `find` with time and permission filters:

```bash
# Files modified in last 24 hours
find /home -type f -mtime -1

# Files modified in last 24 hours with 777 permissions
find /home -type f -mtime -1 -perm 0777

# Files accessed (read) in last hour
find /var/log -type f -amin -60

# Writable files modified in last week
find / -type f -writable -mtime -7 2>/dev/null

# Combine with exec for detailed listing
find / -type f -perm -4000 -mtime -30 -exec ls -l {} \; 2>/dev/null
```

**Time options:**
- `-mtime N`: Modified N days ago
- `-mtime -N`: Modified within last N days
- `-mtime +N`: Modified more than N days ago
- `-amin N`: Accessed N minutes ago (follow same +/- rules)

### 5. Can I remove execute permission from a directory? What happens?

Yes, but it prevents you from **entering** the directory:

```bash
# Create a test directory
mkdir test_dir
cd test_dir
touch file1.txt file2.txt
cd ..

# Remove execute permission
chmod -x test_dir
ls -ld test_dir
# drw-rw-rw- 2 kali kali 4096 Jan 15 12:00 test_dir

# Try to list contents
ls test_dir
# ls: cannot access 'test_dir/file1.txt': Permission denied

# Try to cd into it
cd test_dir
# bash: cd: test_dir: Permission denied

# You can still see it exists
ls -ld test_dir # This works

# But can't do anything with its contents
cat test_dir/file1.txt # Permission denied
```

**Directory permissions summary:**
- **r (read)**: List contents (`ls`)
- **w (write)**: Create/delete files inside (requires execute too)
- **x (execute)**: Enter directory (`cd`), access files inside

**Unusual combinations:**
- `r--` (4): Can list names but can't access files or cd
- `-wx` (3): Can create/delete files if you know names, but can't list directory
- `--x` (1): Can access files if you know their names, but can't list directory

**Most common:**
- `755` (rwxr-xr-x): Standard for shared directories
- `700` (rwx------): Private directories
- `775` (rwxrwxr-x): Group-writable collaboration directories

---

## Conclusion

Linux file permissions are the **foundation of system security**. Mastering `chmod`, `chown`, understanding the permission model, and recognizing security implications are essential skills for any penetration tester, system administrator, or Linux user.

**Key takeaways:**

✅ **Three permission types:** Read (4), write (2), execute (1)
✅ **Three permission classes:** Owner, group, others
✅ **Two notation systems:** Numeric (755) and symbolic (u+rwx)
✅ **Ownership matters:** `chown` and `chgrp` control who owns files
✅ **Special permissions:** SUID, SGID, sticky bit for advanced control
✅ **Security implications:** SUID binaries and world-writable files are attack vectors
✅ **umask:** Controls default permissions for new files
✅ **Practice:** Hands-on exercises solidify understanding

For more Kali Linux tutorials and penetration testing guides, explore:
- [Kali Linux Setup Guide](/tutorials/kali-linux-setup-essential-post-installation-steps-2026)
- [User Management Essentials](/tutorials/kali-linux-default-password-user-management-guide-for-beginners-2026)
- [Complete Penetration Testing Methodology](/articles/pentest-methodology-the-complete-guide-for-2026)

**Additional resources:**
- [Linux.org Documentation](https://www.linux.org/)
- [Kali Linux Official Docs](https://www.kali.org/docs/)

Master these concepts, practice in your environment, and you'll have a solid foundation for Linux system administration and penetration testing.

---

**Written by Syed Abrar (Andrax Pentester) | Last updated: January 2026**