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.

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

📌 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:

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:

Octal Permission Table

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

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