Permissions

Permissions

Linux permissions are a fundamental part of system security. They determine
who can read, modify or execute files and who can access directories.
Understanding permissions is essential for Linux administration and
cybersecurity because improperly configured permissions can expose sensitive
information or allow unauthorized modification.

In this lesson, students will learn how Linux associates files with owners
and groups and how access is controlled through permission bits.

1. Why Permissions Matter

Imagine a server containing:

application files
database configuration
system logs
user documents
private keys
backup files

Not every user should be able to read or modify all of these resources.
Linux permissions provide a basic mechanism for restricting access.

A security principle that guides permission design is
least privilege: users and processes should receive only
the access they genuinely need.

2. Linux File Ownership

A typical Linux file has an associated:

• Owner user.
• Owner group.
• Permission set.

For example:

-rw-r--r-- 1 student students 1200 notes.txt

The owner is student and the group is
students.

3. Understanding ls -l

The command:

ls -l

can display information such as:

• File type.
• Permissions.
• Number of links.
• Owner.
• Group.
• File size.
• Modification time.
• Filename.

Example:

-rwxr-xr-- 1 student developers 2048 app.sh

The permission portion is:

-rwxr-xr--

4. Breaking Down Permission Symbols

The permission string can be understood in groups:

- rwx r-x r--
  --- --- ---
   |   |   |
 owner group other

The three permission groups are:

• Owner: Permissions assigned to the file owner.
• Group: Permissions assigned to members of the file’s group.
• Other: Permissions assigned to other users.

5. Read Permission

The letter r represents read permission.

For a regular file, read permission normally allows a user to view the
file’s contents.

For a directory, read permission generally allows the user to list directory
entries, subject to other access controls.

6. Write Permission

The letter w represents write permission.

For a regular file, this generally allows modification of its contents.

For a directory, write permission can allow creation, deletion or renaming
of entries, depending on the complete permission configuration.

This distinction is important: directory permissions control operations on
directory entries, not simply the contents of individual files.

7. Execute Permission

The letter x represents execute permission.

For a regular file, execute permission allows it to be executed as a
program when the file is otherwise suitable for execution.

For a directory, execute permission generally means that a user can
traverse the directory and access entries when other required permissions
are present.

8. Permission Example

Consider:

-rwxr-x---

This means:

• Owner: read, write and execute.
• Group: read and execute.
• Others: no permissions.

This can be useful when a file should be accessible to a specific
administrator or team but not to everyone else.

9. Numeric Permissions

Linux also represents permissions using numbers.

The values are combined for each permission group.

For example:

7 = 4 + 2 + 1
5 = 4 + 1
4 = 4

Therefore:

750

can be interpreted as:

• Owner: 7 = read + write + execute.
• Group: 5 = read + execute.
• Others: 0 = no permissions.

10. Changing Permissions with chmod

The chmod command changes permissions.

For example, in a disposable training directory:

chmod 640 notes.txt

This gives:

• Owner: read/write.
• Group: read.
• Others: no access.

The exact permissions needed depend on the file’s purpose.

11. Symbolic chmod Notation

Permissions can also be changed symbolically.

For example:

chmod u+x script.sh

The command adds execute permission for the owner.

Symbolic notation uses categories such as:

• u — user/owner.
• g — group.
• o — others.
• a — all categories.

12. Permission Operators

Common symbolic operators include:

• + — add a permission.
• - — remove a permission.
• = — set the specified permissions.

For example:

chmod g-w report.txt

removes write permission from the group.

13. Changing Ownership with chown

The chown command changes file ownership.

Example syntax:

chown user file.txt

Administrative privileges may be required depending on the operation and
system configuration.

Ownership changes should only be performed when authorized.

14. Changing Group Ownership with chgrp

The chgrp command changes the group associated with a file.

chgrp developers project.txt

This can be useful when a shared project directory needs to be managed by
a particular group.

15. Directory Permissions

Directory permissions deserve special attention.

A directory’s permissions therefore behave differently from a regular
file’s permissions.

16. Why Directory Execute Permission Matters

Suppose a user has read permission on a directory but lacks execute
permission.
They may be able to see directory entries but may not be able to access
the contents of those entries normally.

This is why permission analysis must consider the entire path, not only
the final file.

17. Umask

The umask value influences the default permissions assigned
when new files and directories are created.

View the current value with:

umask

The effective default permissions depend on the application and the
system’s permission-creation rules.

Understanding umask helps administrators avoid unintentionally creating
files that are more accessible than necessary.

18. SUID

The Set User ID (SUID) permission is a special permission
bit that can cause an executable program to run with the effective
permissions of its owner.

SUID can have legitimate administrative uses, but improperly configured
SUID programs can create serious security risks.

Security professionals therefore pay attention to unexpected or
unnecessary SUID executables.

19. SGID

The Set Group ID (SGID) permission is another special
permission bit.

Its behavior differs depending on whether it is applied to a file or
directory.

For directories, SGID can cause newly created files to inherit the
directory’s group, which is useful for controlled team collaboration.

20. Sticky Bit

The sticky bit is commonly associated with shared directories.

A classic example is a temporary directory where many users may create
files but should not normally be able to remove files belonging to other
users merely because the directory is writable.

The sticky bit helps provide this protection.

21. Permission Representation

Special permission bits can appear in ls -l output.
Students should learn to recognize them as part of a broader permission
analysis rather than treating them as ordinary read/write/execute bits.

22. Access Control Lists

Traditional Unix permissions provide owner, group and other access
categories.

Some Linux filesystems also support Access Control Lists (ACLs),
which allow more detailed permissions for additional users and groups.

ACLs can be useful in organizations where the traditional three-category
model is not sufficient.

The presence of ACLs should be considered when investigating unexpected
access behavior.

23. Permissions and Least Privilege

Least privilege means giving an account or process only the access required
to perform its legitimate task.

Examples include:

• A web application should not automatically have access to every user file.
• A logging service should have only the permissions required to write its logs.
• A developer does not necessarily need administrative access to production systems.
• Shared project files should be accessible to the appropriate group rather than everyone.

24. Common Permission Problems

Security problems can occur when:

• Sensitive files are readable by everyone.
• Application directories are unnecessarily writable.
• Executable files have excessive permissions.
• Ownership is incorrect.
• Service accounts receive unnecessary access.
• Temporary files are created with inappropriate permissions.
• Special permission bits are left on unnecessary programs.
• Access is granted broadly instead of according to role.

25. World-Writable Files

A world-writable file can be modified by users outside its intended
ownership or group.

This can be dangerous for sensitive files because unauthorized modification
may affect applications, configurations or scripts.

However, not every world-writable object is automatically a vulnerability.
Context, ownership, location and intended system behavior must be
considered.

26. Sensitive Configuration Files

Configuration files may contain:

• Database connection information.
• API configuration.
• Service settings.
• Access-control rules.
• Application secrets.

Their permissions should prevent unnecessary disclosure or modification.

Security professionals should also remember that correct file permissions
cannot compensate for secrets that have already been exposed elsewhere.

27. Permission Auditing

A basic permission review may include:

1. Identify the file or directory.
2. Check its owner.
3. Check its group.
4. Review read/write/execute permissions.
5. Check parent-directory permissions.
6. Look for ACLs when relevant.
7. Consider special permission bits.
8. Compare access with the intended business or application requirement.

The objective is to determine whether access is appropriate rather than
simply making permissions as restrictive as possible.

28. Useful Permission Commands

Students should become familiar with:

ls -l

stat file.txt

chmod

chown

chgrp

umask

The exact command options should be checked using:

man chmod
man chown
man chgrp
man umask

29. Safe Permission Laboratory

Create a disposable laboratory directory:

mkdir -p ~/dwallnet-permissions-lab
cd ~/dwallnet-permissions-lab

Create a sample file:

echo "Dwallnet Linux permissions laboratory" > training.txt

Inspect the current permissions:

ls -l training.txt

Change the file to a controlled permission set:

chmod 640 training.txt

Inspect the result:

ls -l training.txt

View detailed metadata:

stat training.txt

This exercise should only be performed inside a personal or explicitly
authorized Linux laboratory.

30. Comparing Numeric Permissions

These modes are examples for learning. The correct permissions for a real
file depend on its purpose, ownership and security requirements.

31. PHP Example — Permission Information

PHP can inspect basic filesystem permissions. The following example
displays the permission mode of a fixed training file without changing it.

<?php

$file = __DIR__ . '/training.txt';

if ( file_exists( $file ) ) {

	$permissions = fileperms( $file ) & 0777;

	echo 'Permission mode: ';
	echo htmlspecialchars(
		sprintf( '%03o', $permissions ),
		ENT_QUOTES,
		'UTF-8'
	);

} else {

	echo 'Training file was not found.';
}

This example only reads metadata. It does not modify permissions.

32. PHP Security Consideration

A web application should never assume that a file is safe simply because
the application process can access it.

Applications should:

• Store sensitive files outside publicly accessible web directories when appropriate.
• Use controlled file paths.
• Validate user input.
• Apply least privilege to service accounts.
• Prevent unauthorized file modification.
• Protect configuration and secret files.

33. Permissions in Web Applications

Consider a PHP website running under a web-server account.

If the web application has unnecessary write access to large parts of the
filesystem, a compromise of the application could potentially provide an
attacker with more opportunities to modify files.

Restricting write access can therefore reduce the impact of an application
compromise.

This is one reason least privilege is important for web servers.

34. Permission Investigation Scenario

Suppose an authorized security review discovers that a configuration file
containing sensitive application information can be read by all local
users.

A responsible investigation should:

1. Confirm the file and its intended purpose.
2. Identify the current owner and group.
3. Record the existing permissions.
4. Determine which users or processes actually require access.
5. Check whether ACLs affect the result.
6. Recommend an appropriate least-privilege configuration.
7. Test the application after changes.
8. Document the remediation.

The goal is controlled access, not simply maximum restriction.

35. Security Principle: Least Privilege

Least privilege should be applied to:

• Human users.
• Service accounts.
• Web applications.
• Background processes.
• Automation systems.
• Administrative tools.

The fewer unnecessary privileges a component has, the fewer opportunities
there are for accidental or unauthorized changes.

36. Practical Assignment

Using an authorized Linux virtual machine:

1. Create a directory named dwallnet-permissions-lab.
2. Create three sample files.
3. Use ls -l to inspect their permissions.
4. Explain the owner, group and other permission categories.
5. Change one file to mode 640.
6. Change another training file using symbolic chmod notation.
7. Use stat to inspect metadata.
8. Display the current umask.
9. Explain why a sensitive file should not normally be world-readable.
10. Research the purpose of SUID, SGID and the sticky bit using the manual pages.
11. Explain why web applications should use least-privilege filesystem access.

37. Review Questions

1. What are the three main Linux permission categories?
2. What do read, write and execute permissions mean for regular files?
3. How do directory permissions differ from file permissions?
4. What does ls -l show?
5. What does the numeric permission value 640 mean?
6. What does chmod do?
7. What are chown and chgrp used for?
8. What is the purpose of umask?
9. What is SUID?
10. What is SGID?
11. What is the sticky bit?
12. What is an ACL?
13. Why is least privilege important?
14. Why can excessive web-server write permissions increase security risk?

38. Key Takeaways

• Linux permissions control access to files and directories.
• Files normally have an owner, group and permission set.
• Read, write and execute permissions have different meanings for files and directories.
• ls -l is an important command for permission inspection.
• Numeric permissions use values 4, 2 and 1 for read, write and execute.
• chmod changes permissions.
• chown changes ownership and chgrp changes group ownership.
• umask influences default permissions for newly created objects.
• SUID, SGID and sticky-bit permissions require careful understanding.
• ACLs can provide more detailed access control.
• Least privilege is a central Linux security principle.
• Permission reviews should consider the actual business and security requirements.

39. Conclusion

Linux permissions form one of the most important foundations of system
security. A cybersecurity professional must be able to understand who owns
a file, which users can access it and whether that access is appropriate.

The next lesson will build on permissions by examining
Users and Groups, including user identities, group
membership, root privileges, service accounts and account management.