This project simulates configuring secure access to shared resources in a Linux environment. The objective was to create users and groups, apply least-privilege permissions, troubleshoot access issues, and verify that only authorized users could access shared files.
Status: ✅ Complete
- Linux user and group administration
- Linux permissions and ownership
- Access control and least privilege
- Troubleshooting and root cause analysis
- Technical documentation
- Git and GitHub workflow
- Ubuntu 26.04 LTS (WSL2)
- Bash
- Git
- GitHub
- Visual Studio Code
This project simulates configuring a secure shared project directory for an operations team. Team members require access to shared documentation while preventing unauthorized users from viewing or modifying sensitive files.
The objective was to implement secure user and group management using Linux best practices while applying the Principle of Least Privilege. During implementation, an access issue caused by parent directory permissions required additional troubleshooting before the solution could be successfully verified.
During this project, I:
- Created a Linux user (
alex) and a shared group (cloudsupport). - Configured a shared project directory with secure group ownership.
- Applied least-privilege permissions using
chmodandchgrp. - Investigated and resolved an access issue caused by parent directory permissions.
- Relocated shared resources to
/srv/cloudsupportfollowing Linux filesystem best practices. - Verified access using a secondary user account.
sudo groupadd cloudsupport
sudo useradd -m alex
sudo passwd alex
sudo usermod -aG cloudsupport alex
sudo chgrp cloudsupport /srv/cloudsupport
sudo chmod 770 /srv/cloudsupport
sudo -u alex ls -l /srv/cloudsupport/project-filesAI was used to assist with technical research, improve documentation clarity, and explore potential approaches to Linux user and permission management.
All commands, configurations, troubleshooting steps, and final documentation were manually reviewed, tested, and verified before being included in this project.
The solution was verified by testing access from multiple user accounts and confirming that only authorized users could access the shared project directory.
uid=1001(alex)
groups=1002(alex),1001(cloudsupport)
drwxrwx--- root cloudsupport project-files
-rw-rw---- gabby cloudsupport project-plan.txt
| Test | Result |
|---|---|
| Linux user created | ✅ Passed |
| Linux group created | ✅ Passed |
| User added to shared group | ✅ Passed |
| Ownership configured | ✅ Passed |
| Permissions configured | ✅ Passed |
Access verified using alex |
✅ Passed |
| Unauthorized access prevented | ✅ Passed |
The implementation followed a structured validation process.
- Verified user and group creation before assigning permissions.
- Confirmed group membership using Linux administration commands.
- Tested directory access using a secondary user account.
- Verified ownership and permissions after each configuration change.
- Confirmed that unauthorized users were prevented from accessing shared resources.
This project reinforced that Linux access control depends on both file permissions and directory permissions. During troubleshooting, I discovered that correct file permissions alone were insufficient because execute permission is required on every parent directory in the access path.
Rather than reducing the security of a user's home directory, I relocated the shared resources to /srv/cloudsupport, following Linux filesystem best practices for shared service resources.
The project also strengthened my understanding of how Linux users, groups, ownership, and permissions work together to provide secure access while following the Principle of Least Privilege.
- Configure SetGID for automatic group inheritance.
- Implement POSIX Access Control Lists (ACLs).
- Automate user and group provisioning with Bash.
- Deploy the solution on an AWS EC2 Linux instance.
- Expand the project to demonstrate centralized identity management concepts.