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

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

Directory write without execute is rarely useful because you cannot enter the directory to use that write access. With the sticky bit set on a shared writable directory, users can still create files, but may delete or rename only files they own (or if they own the directory, or are privileged).

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

In the basic owner/group/other model, Linux stops checking as soon as it finds the matching permission category. When ACLs are present (covered later in this chapter), evaluation includes those ACL entries as well — the simple three-class walk is not the whole story.

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: Permission Basics

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. Basics Summary

13. The chmod Command

chmod changes file or directory permissions.

chmod 755 script.sh
chmod 644 config.conf
chmod 600 secret.txt
# Prefer separate modes for directories vs files (recursive 755 marks every file executable):
find website/ -type d -exec chmod 755 {} +
find website/ -type f -exec chmod 644 {} +

14. Symbolic Mode

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

15. Numeric Permission Values

r = 4
w = 2
x = 1

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

16. The chown Command

Change the owner of a file or directory.

chown root file.txt
chown ashu report.txt
chown oracle:dba database.db
# Lab example only — do not give the web service account ownership of an entire web tree:
# chown -R apache:apache /var/www   # insecure for production application code
# Prefer root (or a deploy user) for code, and the service user only on writable paths
# (see the production web scenario later in this chapter).
chown root:root /var/www/app/index.html
chown www-data:www-data /var/www/app/uploads   # Debian/Ubuntu; RHEL often apache or nginx

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

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

19. chmod 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.

20. Hands-on: chmod chown chgrp

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.

21. chmod and Ownership Summary

22. Default Permissions with umask

New files start from base mode 666 and new directories from 777. The umask value clears permission bits from those bases (execute bits are not set on newly created regular files).

umask
umask 022
umask 027
umask -S

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

24. SGID (Set Group ID)

SGID has two common uses:

• On a directory: new files and directories inherit the directory’s group. Useful for shared project trees.
• On an executable: the process runs with the file’s group as its effective GID (similar to how SUID elevates to the file’s owner).

# Shared directory — inherit group AND allow group members to create files
chmod 2775 shared
# drwxrwsr-x   (2755 would inherit group but deny group write)

# Executable — run with file’s group privileges (use sparingly)
chmod 2755 helper
# -rwxr-sr-x

Collaborative project directories commonly use SGID with group write (for example 2775) so team members can create files that inherit the shared group without constantly running chgrp.

25. Sticky Bit

On a sticky directory, users may only delete or rename files they own (unless they own the directory or have privileged capabilities). Other users with write access to the directory cannot remove someone else’s files.

chmod 1777 /shared
drwxrwxrwt

/tmp is the most common example of a directory protected by the sticky bit.

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

27. Production Example

mkdir finance
chmod 2775 finance
setfacl -m u:auditor:rx finance
setfacl -d -m u:auditor:r-- finance
setfacl -m u:auditor:r-- finance/report.txt
getfacl -e finance
getfacl -e finance/report.txt

SGID keeps a shared group on new files in finance. The auditor’s directory ACL grants traversal/listing (rx). Reading file contents still requires a file ACL (or default ACL inheritance) — directory execute alone is not enough. Check the effective rights with getfacl -e because the ACL mask can limit permissions.

28. Special Bits Best Practices

• Use restrictive umask values on production servers.
• Limit SUID executables to trusted programs.
• Use SGID for team collaboration directories.
• Use the sticky bit on shared writable directories.
• Document ACL changes for easier maintenance.

29. Hands-on: umask SUID SGID ACL

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.

30. Special Bits and ACL Summary

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

32. Common Permission Denied Scenarios

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

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

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

36. 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?

37. Hands-on Lab: Troubleshooting

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.

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

39. Glossary

40. 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
• getfacl - Get file access control lists
• setfacl - Set file access control lists
• whoami / id / groups - Inspect current user and group membership

Production Scenario: Securing Web Application

Scenario: Deploy a PHP app under /var/www/app with least privilege. Do not grant the web-service account write access to the entire application tree.

# Prefer a deploy/root-owned tree; web user only needs read (and execute on dirs)
# Debian/Ubuntu web user is often www-data; RHEL-family often apache or nginx
sudo chown -R root:root /var/www/app
sudo find /var/www/app -type d -exec chmod 755 {} \;
sudo find /var/www/app -type f -exec chmod 644 {} \;

# Secrets: readable only by the service account (adjust WEBUSER for your distro)
# WEBUSER=www-data   # Debian/Ubuntu
# WEBUSER=apache     # RHEL/Rocky with httpd (or nginx for nginx)
WEBUSER=www-data
sudo chown root:"$WEBUSER" /var/www/app/config/database.php
sudo chmod 640 /var/www/app/config/database.php

# Writable runtime path only (uploads/cache) — not the whole codebase
sudo mkdir -p /var/www/app/uploads
sudo chown "$WEBUSER":"$WEBUSER" /var/www/app/uploads
sudo chmod 750 /var/www/app/uploads

This follows least privilege: application code stays non-writable by the service account, while uploads remain writable. Correct ownership reduces damage from a compromised process; it does not by itself prevent web shells or other application vulnerabilities.