Use Linux Commands to Manage File Permissions

Purpose

I spent this lab using Linux commands to manage file and directory permissions. It was a solid way to get more hands-on practice for the Google Cybersecurity Professional Certificate.

My goal was to get a better handle on how permissions dictate who can read, modify, or access files, and how I can use Linux commands to fix any misconfigurations.

Scenario

For this task, I had to examine and manage file permissions within the /home/researcher2/projects directory for the researcher2 user, who is part of the research_team group.

I had to review the permissions for every file in the directory, including the hidden ones, to make sure they matched the required access levels.

I broke the task down into three parts to see how the pieces fit together.
First, I checked the existing permissions of the files and directories.
Next, I identified files with incorrect permissions and changed them as needed.
Finally, I reviewed the /home/researcher2/projects/drafts directory and removed access that should not have been available to other users.

Getting Comfortable with File and Directory Details

I started the lab in the /home/researcher2 directory. From there, I explored the project's directory to see what was inside and checked the permissions on each file.

I used the command:

When I ran the command, I could see both the normal and hidden files, along with their permissions, owners, and groups. It was clear the files belonged to the research_team group, and I noticed a hidden file .project_x.txt that stood out and needed a closer look.

I realized that hidden files are easy to miss since they don't show up with a standard ls command. It’s still important to check them, though, because their permissions can dictate who has access to view or modify them.

In this case, .project_x.txt had permissions that needed to be changed.

Change File Permissions

One of the requirements was that users outside the owner and group should not have write access to files in the projects directory.

I noticed that project_k.txt was writable by other users, so I tightened the permissions using this command:

After making the change, I used ls -la again to verify that the permission had been updated correctly.

I also handled project_m.txt which required stricter permissions. Since only the owner needed to read and write access, I used chmod to lock down the file so the group and other users had no access at all. Verifying the changes afterward gave me a good sense of how these permissions actually restrict access in a real environment.

Practicing File Permissions on Hidden Files

I also noticed the hidden file .project_x.txt had the wrong permissions. The owner and group both had write access, but I needed to restrict that. To meet the requirements, I had to make sure the group could only read the file instead of modifying it.

I first removed write access from the owner and group:

Then I gave the group read access:

Afterward, I checked the permissions again to make sure the file matched the required access.

Change Directory Permissions

The drafts directory had a different requirement. Only the researcher2 user should be able to access it.

After checking the directory permissions with:

I noticed the group also had execute permission, which for a directory, is what actually lets a user enter and access its contents.

Since the group should not have access, I removed that permission using:

I then verified the directory permissions again to confirm that only the intended user could access it.

Summary

This lab was a great way to get hands-on with Linux file and directory permissions. Using ls -la to inspect permissions and chmod to tighten up access that was too open really helped it click. I also learned that I need to be more diligent about checking hidden files and directory-level permissions, rather than just focusing on the visible files.

The biggest takeaway for me was that file permissions are not just about whether a file can be opened. They control exactly who can read, change, or access something, which makes them an important part of protecting a system.