Mastering Linux: User & Permission Management with a Mock Company Project

Introduction

In Linux system administration, managing users, groups, and permissions is one of the most critical skills. It ensures that only the right people have access to sensitive files, while promoting collaboration in shared environments. In this project, we simulate a real-world scenario by creating multiple users, assigning them to groups, and managing access to shared directories and project files. This hands-on approach gives you practical experience with essential commands like adduser, groupadd, usermod, chmod, chown, and id.

Tasks to be Completed

1. Create Groups
   Set up 2 groups (e.g., devs and staff) using groupadd.

2. Create Users
   Add 5 new users with adduser or useradd.

3. Assign Users to Groups
   Use usermod -aG to assign users to the correct group.

4. Set Up a Shared Project Directory
   Create a directory (/home/company_projects) and configure it with the SGID bit so all files inherit the group ownership.

5. Manage Permissions
   Use chmod to enforce rules (e.g., only group members can read/write, others are denied).

6. Test Group Collaboration
   Have one user (e.g., alice) create a file and another group member (e.g., bob) edit it.

7. Confirm that non-members (e.g., carol) cannot access the directory.

8. Change File Ownership

9. Practice with chown and chgrp to assign ownership of files to specific users or groups.

10. Verify and Troubleshoot

11. Use commands like id, groups, ls -l, and stat to confirm changes.

Prerequisites

• Most commands require root privileges. Prefix with sudo when needed, or run as root:
• sudo -i or sudo su - if you want a root shell

Step 1: Create two groups

Choose meaningful group names. Example: devs and staff.

- sudo groupadd devs
- sudo groupadd staff

Verify groups exist:

- getent group devs
- getent group staff

Step 2 : Create five users
Create five user using the command adduser, adduser will prompt for a password and optional info.

• sudo adduser alice

• sudo adduser bob

• sudo adduser carol

• sudo adduser dave

• sudo adduser eve

• logout of the current user to see all new users added

Step 3 :Assign users to groups

• Decide group membership. Example mapping:
• devs: alice, bob
• staff: carol, dave, eve

Add users to groups (use -aG user to each group)

• sudo usermod -aG devs alice
• sudo usermod -aG devs bob
• sudo usermod -aG staff carol
• sudo usermod -aG staff dave
• sudo usermod -aG staff eve

Verify membership:
verify membership by using the command sudo getent group devs and sudo getent group staff

Step 4 : Create a shared project directory

Create a directory that group members can read/write. We'll create a company_projects folder in the home directory:

- mkdir -p /home/company_projects (create a parent directory in the home directory)

• sudo chmod g+s /home/company_projects The g+s (setgid on directory) is what makes a shared project folder behave like a real team workspace.

sudo chown root:devs /home/company_projects

• chown → change owner of a file or directory.
• root:devs
• root = new owner of the directory
• devs = new group of the directory
• /home/company_projects → the target directory.

sudo chmod u+rwx /home/company_projects

• chmod → change file/directory permissions.
• u → refers to the owner of the directory.
• +rwx → add read (r), write (w), and execute (x) permissions.
• Effect: The owner of ~/company_projects can list contents, create/delete files, and enter the directory

sudo chmod g+rwx /home/company_projects

• chmod: change permissions.
• g: refers to the group of the file/directory (in your case, the group might be devs because of sudo chown root:devs).
• +rwx: add three permissions:
• r (read): group members can list the files inside.
• w (write): group members can create new files, delete files, and make changes.
• x (execute): group members can enter the directory and access its contents.

Step 5 : Test the shared directory behavior

switched to the alice account and tried to enter /home/company_projects

• su - alice
• cd /home/company_projects
• touch file_from_alice.txt
• ls
• shows: file_from_alice.txt
• ls -l
• shows a line similar to:
• -rw-rw-r-- 1 alice devs 0 Sep 27 08:40 file_from_alice.txt
• What this shows:
• The file owner is alice.
• The file group is devs — it inherited the directory group (devs) because the parent directory had the setgid bit.
• File permissions are -rw-rw-r-- (owner read/write, group read/write, others read).

5.1 As another devs member (bob), confirm you can edit/delete:

• su - bob
• cd ~/company_projects
• echo "hello" >> testfile_from_alice.txt
• cat testfile_from_alice.txt allowed because group has write permission

5.2 A non-member (e.g., carol, in staff) should be denied because they are not a member of the group devs, they belong to the staff group:

su - carol
cd /home/company_projects
this should fail with "Permission denied"
touch should_fail.txt

Step 6 : Manage file ownership and group on existing files

Set owner and group for a file or directory using the command

sudo chown alice:devs /home/company_projects/somefile.txt
The owner of the directory is alice and now belong to the devs team.

6.1 change only group:

sudo chgrp staff ~/company_projects/some_other_file.txt

Before the command

The directory /home/company_projects had:

• Owner: alice
• Group: devs
• Shown by:
• drwxrwsr-x 2 alice devs 4096 Sep 27 09:15 /home/company_projects
• Step: sudo chgrp staff /home/company_projects
• chgrp = change group ownership
• staff = new group
• So, this command changed the group of the directory from devs ➝ staff.
• Now the directory looks like:
• drwxrwsr-x 2 alice staff 4096 Sep 27 09:15 /home/company_projects

Meaning:

• Owner is still alice
• Group is now staff
• Next: su - carol
• switched to user carol.
• Carol goes into /home/company_projects and creates a file:
• touch man.txt
• Now when you list:
• -rw-rw-r-- 1 carol staff 0 Sep 27 09:53 man.txt
• -rw-rw-r-- 1 alice devs 16 Sep 27 09:23 testfile_from_alice.txt

Why this happened:

• man.txt
• Owner = carol (because she created it).
• Group = staff (because the directory /home/company_projects now belongs to group staff AND it has the setgid bit s set → that s in drwxrwsr-x).
• The setgid bit ensures new files created inside inherit the directory’s group.
• testfile_from_alice.txt
• This was created earlier by Alice when the group was still devs.
• So it keeps alice:devs.

Conclusion

In this project, we explored how Linux handles file ownership, groups, and permissions through practical examples. By using commands such as chown, chgrp, and chmod, we demonstrated how to assign files and directories to specific users and groups, as well as how to control access levels.
A key highlight was the use of the setgid (s) permission on directories, which ensures that newly created files inherit the group ownership of the parent directory. This feature makes collaboration easier in shared project folders, as users automatically create files that belong to the intended group.
From the exercises, we saw how ownership transitions (e.g., alice:devs ➝ alice:staff) affect who can read, write, or execute within shared directories, and how different users (alice, carol, etc.) interact with files depending on group membership.

Overall, this project demonstrates the importance of carefully managing permissions in multi-user environments. By applying these principles, system administrators can create secure, collaborative workspaces while maintaining control and accountability over files and directories.