DAY 04: The Fortress Guardian

Introduction

Welcome to Day 4 at LabEx Corporation, Fortress Guardian! After your brilliant detective work yesterday in solving Project Phoenix's critical issues, the company's Chief Technology Officer has personally assigned you to lead security for the entire project.

"We can't afford another security incident," the CTO explains during your morning briefing. "Your investigation revealed that our previous security setup was inadequate. Sarah Chen and the development team need a bulletproof environment to complete Project Phoenix on schedule."

The recent crisis has highlighted the need for robust security measures. A new contractor will be joining the team to help accelerate development, and you must ensure that access controls are perfectly configured. You'll need to create secure file systems, assign precise ownership, set granular permissions, and establish collaborative workspaces that protect TechNova's intellectual property.

The success of Project Phoenix—and the company's future—now depends on the digital fortress you build today. Let's secure this system!

Creating a Secure File for a New Project

Your first task is to create a file that will store sensitive project keys. This file must be strictly confidential and accessible only by its owner.

Tasks

• Create a new, empty file named project_keys.txt inside the ~/project/phoenix_project directory.
• Set the permissions for this file so that only the owner has read and write access, and no one else (not even users in the same group) has any access.

Requirements

• The file must be named project_keys.txt.
• The file must be located at ~/project/phoenix_project/project_keys.txt.
• Use the chmod command with numeric notation to set the permissions.

Hints

• You can create an empty file using the touch command.
• Remember the numeric values for permissions: read (4), write (2), and execute (1).
• The final permission should be 600 (read+write for owner, nothing for group and others).

Examples

After completing this task, you should see something like:

$ ls -l ~/project/phoenix_project/
-rw------- 1 labex labex 0 Sep 3 16:03 project_keys.txt

The file permissions show -rw-------, indicating:

• Owner has read and write permissions
• Group has no permissions
• Others have no permissions

Assigning Ownership of Project Resources

Project Phoenix is led by Sarah Chen's development team, with the technical lead dev_lead managing the core development work. This user belongs to the developers group that you've been working with throughout the week. You need to transfer ownership of all project files and directories to ensure proper access control.

Tasks

• Change the owner of the ~/project/phoenix_project directory and all its contents to the user dev_lead.
• Change the group owner of the ~/project/phoenix_project directory and all its contents to the developers group.

Requirements

• The user owner must be dev_lead.
• The group owner must be developers.
• The ownership change must apply recursively to all files and subdirectories within ~/project/phoenix_project.
• You must use the chown command.

Hints

• The chown command can change both user and group at the same time using the user:group syntax.
• Look for an option in the chown command that allows it to operate on files and directories recursively. The man chown command is your friend.
• Since the files are currently owned by root, you will need to use sudo to change ownership.

Examples

After completing this task, you should see something like:

$ ls -ld ~/project/phoenix_project/
drwxrwxr-x 4 dev_lead developers 53 Sep 3 16:00 ~/project/phoenix_project/

$ ls -l ~/project/phoenix_project/
total 0
drwxrwxr-x 2 dev_lead developers 27 Sep 3 16:00 docs
-rw------- 1 dev_lead developers 0 Sep 3 16:03 project_keys.txt
drwxrwxr-x 2 dev_lead developers 6 Sep 3 16:00 src

All files and directories should now be owned by:

• User: dev_lead
• Group: developers

Securing the Main Project Directory

Now that the ownership is correct, you need to set the base permissions for the main project directory, ~/project/phoenix_project. The policy is as follows: the owner should have full control, the group should be able to list files and enter the directory, and outsiders should have no access at all.

Tasks

• Set the permissions for the ~/project/phoenix_project directory.

Requirements

• The owner (dev_lead) must have read, write, and execute permissions.
• The group (developers) must have read and execute permissions.
• Others must have no permissions.
• Use the chmod command to apply these permissions to the ~/project/phoenix_project directory itself (not recursively).
• Since the directory is owned by dev_lead, you may need to use sudo to change permissions.

Hints

• "Execute" permission on a directory allows you to cd into it.
• Calculate the numeric permission value for owner, group, and others.
• Owner (rwx) = 4+2+1 = 7
• Group (r-x) = 4+0+1 = 5
• Others (---) = 0+0+0 = 0

Examples

After completing this task, you should see something like:

$ ls -ld ~/project/phoenix_project/
drwxr-x--- 4 dev_lead developers 53 Sep 3 16:00 ~/project/phoenix_project/

The directory permissions show drwxr-x---, indicating:

• Owner (dev_lead) has read, write, and execute permissions
• Group (developers) has read and execute permissions
• Others have no permissions

This means:

• dev_lead can fully access the directory
• developers group members can list contents and enter the directory
• Outsiders have no access to the directory

Setting Up Collaborative Permissions for the Dev Team

Note: Make sure you have completed Step 2 first, which sets the ownership of all project directories (including src) to dev_lead:developers. This step builds upon those ownership settings.

The setup script adds the labex user to the developers group, but your current shell may not pick up that new group membership automatically. Before you test access in ~/project/phoenix_project/src, run newgrp developers in the terminal. Otherwise, you may see Permission denied errors even when your ownership and permissions are correct.

The development team needs to collaborate effectively within the ~/project/phoenix_project/src directory. To ensure smooth collaboration, any new file or directory created inside src should automatically belong to the developers group. This special permission affects the group owner only. The user owner will still be the account that creates the file, and the file's read/write permissions will still depend on that user's umask.

Tasks

• Set a special permission on the ~/project/phoenix_project/src directory that forces all new files and subdirectories created within it to inherit the group ownership from the src directory itself (which is developers).

Requirements

• The solution must ensure new files in ~/project/phoenix_project/src automatically inherit the developers group.
• The final permissions must allow both the owner and the developers group to read, write, and enter the src directory, while others have no access.
• You must use the chmod command to set this special permission.
• You may need to use sudo to set permissions on directories owned by other users.

Hints

• This special permission is called the "set group ID" or setgid bit.
• You can apply the setgid bit using either symbolic (g+s) or numeric notation.
• In numeric notation, the setgid bit has a value of 2. It is placed before the standard three permission digits (e.g., 2770).

Examples

After completing this task, you should see something like:

$ ls -ld ~/project/phoenix_project/src/
drwxrws--- 2 dev_lead developers 6 Sep 3 16:00 ~/project/phoenix_project/src/

The s in the group execute position indicates the setgid bit is set and the group has execute permission. Now when you create a new file:

$ touch ~/project/phoenix_project/src/new_file.txt
$ ls -l ~/project/phoenix_project/src/new_file.txt
-rw-rw-r-- 1 labex developers 0 Apr 15 18:28 /home/labex/project/phoenix_project/src/new_file.txt

Notice that the new file automatically belongs to the developers group, even if you are logged in as a different user. The file owner still remains the user who created the file, while the group owner is inherited from the src directory. This ensures collaborative work within the development team while maintaining proper group ownership.

The permissions show:

• Owner (dev_lead) has read, write, and execute permissions
• Group (developers) has read, write, and execute permissions
• Others have no permissions
• The lowercase s in the group execute position indicates the setgid bit is set and the group has execute permission

Summary

Outstanding work, Fortress Guardian! You have successfully built an impenetrable security foundation for Project Phoenix. The CTO and Sarah Chen are amazed by your comprehensive security implementation. The project directory is now a fortress that will protect TechNova's intellectual property while enabling seamless collaboration.

Throughout this challenge, you've mastered critical Linux security skills:

• Creating Files and Basic Permissions: You secured sensitive project keys with precise permission controls.
• Ownership Management: You expertly assigned ownership to Sarah's development team and technical leadership.
• Directory Security: You balanced access and security for the main project infrastructure.
• Advanced Permissions: You configured setgid permissions to ensure collaborative team workspaces with automatic group ownership inheritance.
• Collaborative Workspaces: You configured team collaboration spaces that maintain security while enabling productivity.

These advanced security skills have proven your readiness for senior system administration responsibilities. Tomorrow, you'll take on your final challenge as the Keeper of the Keys, managing the human element of Project Phoenix's security by controlling user access to the system!