RED HAT ENTERPRISE LINUX
File Permissions
Set Standard Permissions & Interpret Security Effects
CIS126RH | RHEL System Administration 1
Welcome to this module on Linux file permissions. This is one of the most fundamental security concepts in Linux and RHEL. Understanding permissions is essential for any system administrator because it controls who can read, write, and execute files on the system. Today we'll learn how to interpret permission strings, set permissions using both symbolic and octal notation, and understand the security implications of different permission settings. By the end of this module, you'll be able to confidently manage file access on any Linux system.
Learning Objectives
1
Interpret permission strings
Read and understand rwx notation in ls -l output
2
Set permissions with chmod
Use symbolic and octal methods to modify access
3
Understand owner, group, and other
Know how Linux determines which permissions apply
4
Analyze security implications
Evaluate the effects of different permission settings
Let's review what we'll cover today. First, you'll learn to read and interpret permission strings - those rwx characters you see in ls -l output. Second, we'll master chmod, the command for changing permissions, using both symbolic notation like u+x and octal notation like 755. Third, we'll understand the three categories of users: owner, group, and other, and how Linux decides which permissions apply to each user. Finally, we'll analyze the security implications of different permission settings so you can make informed decisions about file access. These skills are tested on the RHCSA exam and are essential for daily administration work.
The Linux Permission Model
Every file and directory has three sets of permissions for three categories of users:
Owner (u)
The user who owns the file
Group (g)
Members of the file's group
Other (o)
Everyone else on the system
Key Concept: Linux checks permissions in order: owner first, then group, then other. Once a match is found, those permissions apply.
Linux uses a three-tier permission model. Every file has an owner - typically the user who created it. Every file also belongs to a group, and finally there's everyone else, called "other" or sometimes "world." When you access a file, Linux checks: Are you the owner? If yes, owner permissions apply. If not, are you in the file's group? If yes, group permissions apply. If neither, other permissions apply. This is important: Linux stops checking at the first match. So if you're the owner, only owner permissions apply even if group permissions would give you more access. Understanding this hierarchy is crucial for troubleshooting access issues.
Permission Types: r w x
Permission
Symbol
On Files
On Directories
Read r
View file contents
List directory contents (ls)
Write w
Modify file contents
Create/delete files in directory
Execute x
Run as program/script
Enter directory (cd)
⚠ Important: Directory permissions work differently! Without x on a directory, you cannot cd into it even with r permission.
There are three permission types: read, write, and execute. For files, these are intuitive - read lets you view contents, write lets you modify, execute lets you run the file as a program. But for directories, they work differently! Read on a directory lets you list its contents with ls. Write lets you create or delete files within that directory - this is crucial for understanding why someone might delete a file they can't read. Execute on a directory is often overlooked but essential - it allows you to cd into the directory and access files within it. Here's a common gotcha: if you have read but not execute on a directory, you can see filenames but can't actually access the files or their metadata. You need execute permission to traverse into a directory.
Reading Permission Strings
-rwxr-xr-- 1 alice developers 4096 Dec 5 10:30 script.sh
Position 1: File type (- = file, d = directory, l = link)
Positions 2-4: Owner permissions (rwx)
Positions 5-7: Group permissions (r-x)
Positions 8-10: Other permissions (r--)
Let's break down a permission string from ls -l output. The first character indicates the file type - a dash means regular file, d means directory, l means symbolic link. The next nine characters are permissions in three groups of three. Characters 2-4 are owner permissions - in this example, rwx means the owner alice can read, write, and execute. Characters 5-7 are group permissions - r-x means members of the developers group can read and execute but not write. Characters 8-10 are other permissions - r-- means everyone else can only read. A dash in any position means that permission is not granted. This visual breakdown is how you quickly assess who can do what with a file.
Octal Notation
Each permission has a numeric value:
Add values together for each category:
rwx = 4+2+1 = 7
r-x = 4+0+1 = 5
r-- = 4+0+0 = 4
Combined: 754
Octal notation is a numeric shorthand for permissions. Each permission type has a value: read is 4, write is 2, execute is 1. These values are designed so any combination gives a unique sum from 0 to 7. To calculate the octal value for a permission set, add the values together. rwx is 4+2+1=7, the maximum. r-x is 4+0+1=5. r-- is just 4. You then combine three digits, one for each category. So our example of rwxr-xr-- becomes 754. The first digit is owner, second is group, third is other. Common values you'll see: 755 for executables and directories, 644 for regular files, 700 for private files. Memorizing these common patterns will speed up your administration work.
chmod Symbolic Mode
Who
u - owner (user)g - groupo - othera - all (u+g+o)
Operators
+ - add permission- - remove permission= - set exactly
chmod u+x script.sh
chmod g-w file.txt
chmod o=r document.pdf
chmod a+r public.html
chmod ug+rw,o-rwx secret
The chmod command changes file permissions. Symbolic mode is intuitive and self-documenting. The syntax has three parts: who, operator, and permission. "Who" specifies the category: u for user/owner, g for group, o for other, or a for all three. The operator determines the action: plus adds permissions, minus removes them, equals sets them exactly. Then specify which permissions: r, w, x, or any combination. You can combine multiple changes with commas. For example, ug+rw,o-rwx adds read-write to owner and group while removing all permissions from other. Symbolic mode is great when you want to modify specific permissions without affecting others - like adding execute without changing read or write.
chmod Octal Mode
Octal
Symbolic
Meaning
Common Use
755rwxr-xr-xOwner full, others read/execute
Executables, directories
644rw-r--r--Owner read/write, others read
Regular files
700rwx------Owner only, full access
Private scripts, ~/.ssh
600rw-------Owner only, read/write
Private keys, configs
777rwxrwxrwxEveryone full access
⚠ Avoid - security risk
chmod 755 script.sh
chmod 644 config.txt
chmod 600 id_rsa
Octal mode sets all permissions at once with a three-digit number. This is faster when you know exactly what permissions you want. Let's review common values: 755 is the standard for executables and directories - owner has full control, everyone can read and execute but not modify. 644 is typical for regular files - owner can edit, everyone can read. 700 is for private executables like personal scripts or the .ssh directory - only the owner has any access. 600 is for sensitive files like SSH private keys - SSH actually refuses to use keys with more permissive settings. 777 gives everyone full access and should almost never be used - it's a common but dangerous shortcut that creates security vulnerabilities. When in doubt, start restrictive and add permissions as needed.
Changing Ownership
chown - Change Owner
chown alice file.txt
chown alice:developers file.txt
chown -R alice:team /project
chgrp - Change Group
chgrp developers file.txt
chgrp -R webteam /var/www
Note: Only root can change file ownership. Regular users can only change group to a group they belong to.
Besides permissions, you may need to change file ownership. The chown command changes the owner, and optionally the group. The syntax is chown owner:group file. You can omit either part - chown alice changes just the owner, chown :developers changes just the group. The chgrp command is dedicated to changing just the group. Both support -R for recursive changes to entire directory trees. An important security restriction: only root can change file ownership. This prevents users from giving away their files to escape quota limits or hide malicious files. Regular users can use chgrp but only to groups they're members of. These restrictions are fundamental to Linux security.
Security Implications
⚠ Common Security Mistakes
chmod 777 - Never use! Anyone can modify or executeWorld-writable directories - Allow file deletion by anyoneExecutable configs - Configuration files rarely need xOverly permissive /home - Others shouldn't read your files
✓ Best Practices
Start restrictive (600/700), add permissions as needed
SSH keys must be 600 or SSH refuses to use them
Web files: 644 for files, 755 for directories
Use groups for team collaboration instead of world permissions
Let's discuss security implications. The most common mistake is using chmod 777 as a quick fix for access problems. This gives everyone full access and is almost never the right solution. World-writable directories are dangerous because write permission on a directory means you can delete ANY file in it, even files you can't read. Another mistake is making config files executable - they're read by programs, not executed. Your home directory shouldn't be readable by others - use 700 or 750. Best practices: always start with restrictive permissions and only add what's needed. SSH has built-in security - it refuses to use private keys that aren't 600. For web content, 644 for files and 755 for directories is standard. When multiple users need access, create a group and use group permissions rather than opening files to the world.
Real-World Scenarios
Scenario 1: Web server needs to read files but not modify them
chown developer:apache /var/www/html/index.html
chmod 640 /var/www/html/index.htmlOwner (developer) can edit; group (apache) can read; others denied
Scenario 2: Shared project directory for a team
chown -R :projectteam /shared/project
chmod 2775 /shared/projectGroup members can create/modify; new files inherit group (setgid)
Scenario 3: Private SSH configuration
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pubSSH directory private; private key restricted; public key readable
Let's look at real-world permission scenarios. First, a web server setup: the developer owns the file and can edit it. The apache group, which the web server process runs as, has read access to serve the content. Others are denied access for security. Note we use 640, not 644 - there's no need for world-readable web files when the server is in the group. Second, a shared project directory: we use group ownership and 2775 permissions. The 2 is the setgid bit - it makes new files inherit the directory's group automatically, so team members don't have to manually fix group ownership. Third, SSH configuration: the .ssh directory must be 700, private keys 600, public keys can be 644. SSH is strict about these - it won't use keys with wrong permissions. These patterns come up constantly in system administration.
Viewing & Troubleshooting
ls -l file.txt
-rw-r--r-- 1 alice developers 1024 Dec 5 script.sh
stat -c "%a %n" file.txt
644 file.txt
groups
alice developers wheel
stat -c "%U:%G" file.txt
alice:developers
find /path -perm 777 -type f
find /path -perm -002 -type f
Troubleshooting tip: "Permission denied"? Check: 1) File permissions 2) Directory permissions on path 3) Your user/group membership
Here are essential commands for viewing and troubleshooting permissions. ls -l shows the symbolic permissions along with owner and group. stat with format strings can show octal permissions directly - useful when you need the numeric value. The groups command shows what groups you belong to - remember, group permissions only apply if you're in the file's group. stat can also show ownership information. The find command is powerful for auditing - find files with exactly 777 permissions, or find world-writable files using -perm -002. When troubleshooting "permission denied" errors, check three things: the file's permissions, the permissions on every directory in the path (you need x to traverse), and whether you're actually in the group you think you're in. Groups membership changes require logout/login to take effect.
Key Takeaways
1
Permissions are r ead, w rite, ex ecute for owner , group , and other
2
Use chmod with symbolic (u+x) or octal (755) notation
3
Directory x permission is required to access contents
4
Start restrictive (600/700) and add permissions as needed
Next: Installing and Updating Software with RPM
Let's summarize what we've learned. First, Linux permissions consist of read, write, and execute for three categories: owner, group, and other. Linux checks these in order and uses the first match. Second, chmod is our tool for changing permissions, with two syntaxes: symbolic for targeted changes, octal for setting exact values. Third, remember that directory execute permission is required to access anything inside - this trips up many administrators. Fourth, always start with restrictive permissions. It's much safer to start at 600 or 700 and add access than to start permissive and try to lock things down.
Graded Lab
Create files and practice setting permissions with chmod
Test access as different users to verify permissions work
Set up a shared directory with proper group permissions
Audit your system for world-writable files
Next: Installing and Updating Software with RPM
In your lab exercises, create files with different permissions and test access. Set up a shared directory using group permissions. And audit your system for overly permissive files.