Day 5: Master Linux Permissions for Secure DevOps & Cloud

Struggling with Linux permissions? 🚀 Understanding file permissions is crucial for security, access control, and automation in DevOps & Cloud environments. Let’s break it down!

Why Are Permissions Important in DevOps & Cloud?

Key Reasons:

• Security: Prevent unauthorized access to sensitive files.
• Access Control: Assign roles to users, applications, and services.
• Automation & Compliance: Ensure DevOps pipelines and cloud resources follow best security practices.
• Multi-Tenant Environments: Protect cloud-based applications from unauthorized modifications.

Command	Description	Use Cases
ls -l	Lists files with detailed permissions, owner, and group.	Check file permissions before modifying configurations.
chmod	Changes file permissions using octal (755) or symbolic (u+x).	Grant or restrict access to files and directories.
umask	Sets default permissions for newly created files and directories.	Ensure secure default permissions for logs, configs, and temp files.
chown	Changes the owner of a file or directory.	Transfer file ownership in shared environments.
chgrp	Changes the group ownership of a file or directory.	Assign permissions to a team without affecting file ownership.

Essential Linux Permission Commands

1. ls -l – View File Permissions

Usage: Lists files with their permissions, ownership, and details.
How It Works:

• Reads metadata from the filesystem.

Example:

ls -l file.txt

Output:

-rw-r--r-- 1 devops users  1024 Jan 18 12:00 file.txt

📌 Best Practice: Use ls -lah to list all files, including hidden ones.

2. chmod – Change File Permissions

Usage: Modifies file permissions.
How It Works:

• Updates file permission bits in the filesystem.

Example (Symbolic Method):

chmod u+x script.sh  # Give execute permission to the user
chmod g-w file.txt   # Remove write permission from the group
chmod o+r file.txt   # Give read permission to others

Example (Octal Method):

chmod 755 script.sh

Explanation (755):

• 7 (Owner) = Read (4) + Write (2) + Execute (1)
• 5 (Group) = Read (4) + Execute (1)
• 5 (Others) = Read (4) + Execute (1)

📌 Best Practice: Use chmod -R 700 dir_name/ to apply changes recursively.

3. umask – Default Permission Mask

umask (User Mask) controls the default permissions assigned to new files and directories.

It subtracts from the maximum possible permissions:

• Files default to 666 (rw-rw-rw-)
• Directories default to 777 (rwxrwxrwx)

umask is critical for security in DevOps & Cloud environments to prevent unauthorized access.

Usage: Defines the default permissions for new files and directories.
How It Works:

• When a user creates a new file or directory, the system subtracts the umask value from the default permissions:

Formula for Effective Permissions:

New File Permissions  = Default File Permissions  - umask
New Directory Permissions = Default Directory Permissions - umask

Default Permissions	umask Value	Final Permissions
File: 666	0022	644 → rw-r--r--
File: 666	0002	664 → rw-rw-r--
Directory: 777	0022	755 → rwxr-xr-x
Directory: 777	0002	775 → rwxrwxr-x

📌 Important:

• New files do not get execute (x) permission by default.
• New directories retain execute (x) permission so users can enter them.

Checking Current umask Value:

umask

Output:

0022

Set a Permanent umask (System-Wide)

To make umask changes persist across reboots, modify:

• For all users: Add to /etc/profile or /etc/bash.bashrc
• For a specific user: Add to ~/.bashrc or ~/.profile

echo "umask 0077" >> ~/.bashrc
source ~/.bashrc  # Apply changes immediately

📌 Best Practice: Set a restrictive umask in DevOps environments to improve security.

4. chown – Change File Ownership

Usage: Modifies the owner of a file.
How It Works:

• Updates ownership metadata in the filesystem.

Example:

sudo chown devops file.txt   # Change file owner to 'devops'
sudo chown -R devops:users mydir/  # Change owner and group recursively

📌 Best Practice: Use chown -R when managing directories in CI/CD pipelines.

5. chgrp – Change Group Ownership

Usage: Modifies the group ownership of a file.
How It Works:

• Changes the group attribute in the filesystem.

Example:

sudo chgrp admins file.txt

📌 Best Practice: Assign group-based permissions to improve access control in cloud environments.

Answering Common Questions on Linux Permissions

1. How Can We Check Permissions?

Use ls -l:

ls -l file.txt

Example Output:

-rw-r--r-- 1 devops users  1024 Jan 18 12:00 file.txt

2. How to Read Permissions in Pairs?

Each permission section consists of three parts:

Owner (User)	Group	Others
rw-	r--	r--

Explanation:

• Owner (rw-) = Read & Write
• Group (r--) = Read-only
• Others (r--) = Read-only

3. How to Read Permissions as Single Characters?

Permissions are read as:

• r → Read
• w → Write
• x → Execute
• - → No Permission

Example:

-rwxr-x--x

• Owner (rwx) = Read, Write, Execute
• Group (r-x) = Read, Execute
• Others (--x) = Execute-only

4. Permissions in Octal Numbers

Each permission has a numeric value:

Permission	Symbolic	Octal
No Access	---	0
Execute	--x	1
Write	-w-	2
Write + Execute	-wx	3
Read	r--	4
Read + Execute	r-x	5
Read + Write	rw-	6
Read + Write + Execute	rwx	7

Octal Permission Table

Octal	Binary	Permission
0	000	---
1	001	--x
2	010	-w-
3	011	-wx
4	100	r--
5	101	r-x
6	110	rw-
7	111	rwx

5. How to Remember Permission Values?

Each permission adds up:

• Read (r) = 4
• Write (w) = 2
• Execute (x) = 1

Example:

chmod 755 script.sh

• 7 (Owner) = rwx
• 5 (Group) = r-x
• 5 (Others) = r-x

6. umask Table

Default Permissions	umask Value	Final Permission
Directory: 777	0022	755 (rwxr-xr-x)
File: 666	0022	644 (rw-r--r--)
Directory: 777	0002	775 (rwxrwxr-x)
File: 666	0002	664 (rw-rw-r--)

7. Default umask Value

• Most Linux systems use 022.
• Resulting file permissions: 644 for files, 755 for directories.

8. How to Change umask Value?

umask 0077  # More restrictive (700 for dirs, 600 for files)
umask 0002  # Less restrictive (775 for dirs, 664 for files)

9. How to Check if It’s a Directory or File Using Permissions?

Use ls -l:

• If the first character is d → Directory
• If the first character is - → File

Example:

drwxr-xr-x 2 devops users  4096 Jan 18 12:00 mydir/  # Directory
-rw-r--r-- 1 devops users  1024 Jan 18 12:00 file.txt  # File

Complete User and File Permission Management for a Rails Project🚀

Scenario:
You are managing a Rails application with two types of users:

• Development Team (dev1, dev2) → Can only view logs but cannot modify application files.
• DevOps Team (devops1, devops2, devops3) → Can manage Rails files, restart Nginx and Puma but cannot modify security-sensitive files.

Solution:
We will use user groups, file permissions, chmod, chown, chgrp, and sudoers to set up proper security measures.

📌 Step 1: Create Users

We will create users for development and DevOps teams.

# Create Development Users
sudo useradd -m -s /bin/bash dev1
sudo useradd -m -s /bin/bash dev2

# Create DevOps Users
sudo useradd -m -s /bin/bash devops1
sudo useradd -m -s /bin/bash devops2
sudo useradd -m -s /bin/bash devops3

📌 Best Practice: Use -m to create a home directory.

📌 Step 2: Create User Groups

# Create a group for developers to access logs
sudo groupadd developers

# Create a group for DevOps engineers
sudo groupadd devops_team

📌 Why?

• Developers should be in developers group for log access.
• DevOps team should be in devops_team for Rails and server management.

Step 3: Assign Users to Groups

# Add developers to the developers group
sudo usermod -aG developers dev1
sudo usermod -aG developers dev2

# Add DevOps users to devops_team
sudo usermod -aG devops_team devops1
sudo usermod -aG devops_team devops2
sudo usermod -aG devops_team devops3

📌 Why?

• Developers (dev1, dev2) cannot modify the Rails app but can view logs.
• DevOps (devops1, devops2, devops3) can manage Rails files and restart servers.

📌 Step 4: Set Permissions for Rails Files

Restrict Access to Rails App for Developers

# Set ownership to devops_team
sudo chown -R root:devops_team /var/www/rails_app

# Give full access to devops_team, read access to others
sudo chmod -R 750 /var/www/rails_app

📌 Outcome:

• DevOps can modify files (rwx).
• Developers can’t edit (r--) but can see files.

Allow Developers to Read Logs

# Change ownership to developers group
sudo chown -R root:developers /var/log/nginx
sudo chown -R root:developers /var/www/rails_app/log

# Give developers read-only access
sudo chmod -R 740 /var/log/nginx
sudo chmod -R 740 /var/www/rails_app/log

📌 Outcome:

• Developers (dev1, dev2) can view logs but cannot modify them.
• Only DevOps (devops1, devops2, devops3) can modify logs.

📌 Step 5: Allow DevOps Users to Restart Nginx & Puma

We need to grant sudo privileges to DevOps users for specific tasks.

Edit Sudoers File

sudo visudo

Add the Following Lines

%devops_team ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx, /bin/systemctl restart puma

📌 Outcome:

• DevOps users can restart Nginx and Puma without full sudo access.

📌 Step 6: Test the Permissions

Check File Permissions

ls -ld /var/www/rails_app /var/log/nginx

Expected Output:

drwxr-x--- 3 root devops_team 4096 Jan 18 12:00 /var/www/rails_app
drwxr----- 2 root developers  4096 Jan 18 12:00 /var/log/nginx

Developer (dev1) Should Be Able to View Logs

su - dev1
cat /var/log/nginx/access.log  # Should work
cat /var/www/rails_app/config/database.yml  # Permission denied

DevOps (devops1) Should Be Able to Restart Servers

su - devops1
sudo systemctl restart nginx  # Should work
sudo systemctl restart puma  # Should work

📌 Final Summary

User Type	Permissions
Developers (dev1, dev2)	Can view logs but cannot modify files.
DevOps (devops1, devops2, devops3)	Can modify Rails files and restart Nginx & Puma.