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
2. Viewing File Permissions
3. Numeric Permission Notation
4. Symbolic Permission Notation
5. The chmod Command
6. Ownership: chown and chgrp
7. Special Permissions Explained
8. Understanding umask
9. Permission Security Implications for Pentesters
10. Practical Exercises
11. 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:

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.

Viewing File Permissions

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

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

# 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:

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

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

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

Multiple changes can be combined with commas:

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

chmod [options] mode file

Using Numeric Mode

# 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

# 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:

# 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

# 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

# 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:

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:

chown [options] user[:group] file

Examples:

# 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:

# 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:

# 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:

# Create shared directory
sudo mkdir /home/shared
sudo chown root:developers /home/shared
sudo chmod 770 /home/shared

Fixing ownership after sudo operations:

# 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:

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:

# 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:

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

Example - SGID Directory:

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:

# 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:

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:

# 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

Combining Special and Standard Permissions

# 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

# 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

Making umask Permanent

Add to your shell configuration file:

# 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, 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:

# 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:

# 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:

# 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:

# 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:

# 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:

# 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:

# 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:

# 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):

# 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.

Practical Exercises

Reinforce your understanding with these hands-on exercises in your Kali Linux virtual machine:

Exercise 1: Permission Basics

# 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

# 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

# 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

# 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

# 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):

# 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:

# 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, 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:

# 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:

# 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
• User Management Essentials
• Complete Penetration Testing Methodology

Additional resources:

• Linux.org Documentation
• Kali Linux Official 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