Chapter 3: Linux Permissions & Ownership

Visual Permission Calculation

Understanding octal permissions is critical for production work:

Example: chmod 755 = rwxr-xr-x = Owner: rwx, Group: r-x, Others: r-x

Table of Contents

• Visual Permission Calculation
• Commands Covered
• Production Scenario
• Chapter Navigation
• 🎯 Learning Objectives

• Group

• Others

• 🎯 Learning Objectives

• 🎯 Learning Objectives

• 🎯 Learning Objectives

• When should ACLs be preferred?

• Why is my script not executable?

1. Introduction

Linux is a multi-user operating system. Hundreds of users and services may share the same server, yet every file remains protected through ownership and permissions. Understanding this model is essential before changing permissions or administering production systems.

2. Why Linux Uses Permissions

• Protect confidential data.
• Prevent accidental modifications.
• Allow multiple users to safely share a server.
• Restrict application access.
• Improve overall system security.

User Request
      │
      ▼
Permission Check
      │
      ▼
Allow  or  Deny

3. Linux Ownership Model

Every file and directory belongs to:

File
 │
 ├── Owner
 ├── Group
 └── Others

4. Users, Groups & Others

Owner

Usually the user who created the file.

Group

Provides shared access without changing ownership.

Others

Represents every remaining user.

$ ls -l report.txt

-rw-r----- 1 ashu developers 2480 Jul 9 report.txt

Owner: ashu
Group: developers

5. Permission Types

6. Reading Permission Strings

-rwxr-xr--

7. How Linux Checks Permissions

User Access Request
        │
        ▼
Is User Owner?
        │
   Yes ─────► Owner Permission
        │
        No
        ▼
Member of Group?
        │
   Yes ─────► Group Permission
        │
        No
        ▼
Others Permission

Linux stops checking as soon as it finds the matching permission category.

8. Real Production Example

-rw-r----- root appadmins application.log

• Owner (root) has full read/write access.
• Members of appadmins can read the log.
• Other users have no access.

9. Useful Commands

whoami
id
groups
ls -l

10. Hands-on Practice

1. Run whoami.
2. Run id.
3. Run groups.
4. Create a test file.
5. View its permissions using ls -l.
6. Identify the owner, group and permission string.

11. Common Mistakes

• Confusing the root user with the root directory.
• Assuming file creator always has permanent ownership.
• Ignoring group permissions.
• Reading only the owner permissions from ls -l.

12. Part 1 Summary

2. The chmod Command

chmod changes file or directory permissions.

chmod 755 script.sh
chmod 644 config.conf
chmod 600 secret.txt
chmod -R 755 website/

3. Symbolic Mode

chmod u+x script.sh
chmod g-w report.txt
chmod o-r secret.txt
chmod a+r file.txt

4. Numeric Permission Values

r = 4
w = 2
x = 1

7 = 4+2+1 = rwx
5 = 4+1   = r-x

5. The chown Command

Change the owner of a file or directory.

chown root file.txt
chown ashu report.txt
chown oracle:dba database.db
chown -R apache:apache /var/www

6. The chgrp Command

chgrp developers report.txt
chgrp dba database.db
chgrp -R webteam website/

Use chgrp when only the group ownership needs to change.

7. Real Production Workflow

ls -l app.conf
cp app.conf app.conf.bak
chown root:appadmins app.conf
chmod 640 app.conf
ls -l app.conf

A common workflow is to inspect permissions, create a backup, update ownership, apply secure permissions and verify the final result.

8. Best Practices

• Grant the minimum permissions required.
• Back up important configuration files before changes.
• Verify with ls -l after using chmod or chown.
• Avoid using 777 unless absolutely necessary.

9. Hands-on Practice

1. Create a test file.
2. Assign permission 644.
3. Change it to 755.
4. Use symbolic mode to add execute permission.
5. Change the group ownership.
6. Verify the changes using ls -l.

10. Part 2 Summary

1. Default Permissions with umask

Every newly created file or directory starts with default permissions. The umask value removes permissions from these defaults.

umask
umask 022
umask 027
umask -S

2. SUID (Set User ID)

SUID allows an executable to run with the permissions of its owner rather than the user executing it.

chmod 4755 program
ls -l program
-rwsr-xr-x

3. SGID (Set Group ID)

SGID causes files created inside a directory to inherit the directory's group.

chmod 2755 shared
drwxr-sr-x

This is useful for collaborative project directories where all team members need a common group.

4. Sticky Bit

The Sticky Bit prevents users from deleting files owned by other users inside a shared directory.

chmod 1777 /shared
drwxrwxrwt

/tmp is the most common example of a directory protected by the Sticky Bit.

5. Access Control Lists (ACLs)

ACLs provide more flexible permissions than the standard owner, group and others model.

getfacl report.txt
setfacl -m u:alice:rwx report.txt
setfacl -x u:alice report.txt

6. Production Example

mkdir finance
chmod 2775 finance
setfacl -m u:auditor:r-x finance
getfacl finance

This configuration allows project members to share files through the SGID directory while granting an auditor read-only access using an ACL.

7. Best Practices

• Use restrictive umask values on production servers.
• Limit SUID executables to trusted programs.
• Use SGID for team collaboration directories.
• Use Sticky Bit on shared writeable directories.
• Document ACL changes for easier maintenance.

8. Hands-on Practice

1. Check the current umask.
2. Create a test directory and observe default permissions.
3. Apply SGID to a directory.
4. Configure a test ACL using setfacl.
5. Verify the ACL using getfacl.

9. Part 3 Summary

1. Production Permission Troubleshooting

Permission issues are among the most common Linux administration problems. A structured approach helps identify the root cause quickly.

Permission Denied
       │
       ▼
Check Owner
       │
       ▼
Check Group
       │
       ▼
Check Permissions
       │
       ▼
Check ACL

whoami
id
ls -l file.txt
getfacl file.txt

2. Common Permission Denied Scenarios

3. Production Workflow

whoami
id
ls -l application.conf
getfacl application.conf
chmod 640 application.conf
chown root:appadmins application.conf
ls -l application.conf

This workflow verifies identity, inspects permissions, checks ACLs, applies corrections and validates the final result.

4. Security Best Practices

• Apply the principle of least privilege.
• Avoid using 777 permissions.
• Grant execute permission only when required.
• Review SUID executables periodically.
• Audit ACL entries regularly.
• Document ownership changes.

5. Common Beginner Mistakes

• Using chmod 777 to solve every problem.
• Changing ownership without understanding application requirements.
• Ignoring inherited group permissions.
• Forgetting recursive changes affect every file.
• Not verifying changes using ls -l.

6. Interview Questions

1. What is the difference between owner, group and others?
2. Explain 755 and 644.
3. What does SUID do?
4. When should SGID be used?
5. Why is the Sticky Bit important?
6. What is the purpose of umask?
7. What are ACLs?
8. Difference between chmod, chown and chgrp?

7. Hands-on Practice Lab

1. Create a shared directory.
2. Apply permission 755.
3. Change ownership to another user.
4. Assign a new group.
5. Configure SGID.
6. Create an ACL for one user.
7. Verify all changes.

8. FAQ

Should I use 777 permissions?

No. Use the minimum permissions required.

When should ACLs be preferred?

When a few users need additional access without changing ownership or primary groups.

Why is my script not executable?

Most commonly because the execute permission has not been granted.

9. Glossary

10. Chapter 3 Summary

📝 Ready for the Quiz?

You've completed Chapter 3. Test your knowledge before moving to the next chapter.

Commands Covered in This Chapter

• chmod - Change file mode bits
• chown - Change file owner and group
• chgrp - Change group ownership
• umask - Set default file creation permissions
• ls -l - Display permissions
• stat - Display file or filesystem status
• getfacl - Get file access control lists
• setfacl - Set file access control lists
• id - Display user and group IDs

Production Scenario: Securing Web Application

Scenario: Deploy a new PHP app to /var/www/app. Need correct permissions.

# Set ownership to web server user
sudo chown -R www-data:www-data /var/www/app

# Directories: 755 (rwxr-xr-x) - owner can write, others can read/execute
find /var/www/app -type d -exec chmod 755 {} \;

# Files: 644 (rw-r--r--) - owner can write, others can read
find /var/www/app -type f -exec chmod 644 {} \;

# Config file: 600 (rw-------) - only owner can read/write
chmod 600 /var/www/app/config/database.php

# Uploads directory: 775 (rwxrwxr-x) - owner and group can write
chmod 775 /var/www/app/uploads

This prevents web shells and follows principle of least privilege.