Linux: Phase 2 Mini Project
This is the Phase 2 capstone project. You'll apply user management, file permissions, and environment variable knowledge to transform a "single-user chaos" scenario into a collaborative multi-user development server.
📋 Prerequisites: You should first complete
- Lesson 8: File Permissions
- Lesson 9: User and Group Management
- Lesson 10: Environment Variables and PATH
1. What You Will Learn
- Team user system design
- Shared directory permission strategy
- Unified umask configuration for teams
- Individual Shell configuration per developer
- sudo privilege management by group
2. Alex's Team Collaboration Nightmare
(1) The Pain: Three People Sharing a Server, Files Getting Mixed Up
Alex's three-person development team shared a cloud server. Everyone logged in as root and nobody managed file permissions — Alex's script was accidentally deleted by a colleague three times, and he couldn't find his own files because they were mixed in with everything in /tmp.
(2) A Standardized Multi-User Environment
Bob helped them design a standard multi-user environment:
# 1. Each person has their own account and home directory
sudo useradd -m -s /bin/bash alice
sudo useradd -m -s /bin/bash bob
sudo useradd -m -s /bin/bash charlie
# 2. Shared project directory (SGID ensures group inheritance)
sudo mkdir -p /srv/project
sudo chgrp developers /srv/project
sudo chmod 2775 /srv/project
(3) The Benefit: Each Person Has Their Own Space, Shared Areas Have Order
Files no longer disappear, everyone has their own independent home directory and Shell configuration, and the shared directory has correct permissions — no one will accidentally delete someone else's files.
3. Knowledge Points
(1) Multi-User Environment Design Principles
| Principle | Description |
|---|---|
| Least privilege | Each user only has the minimum permissions needed to do their job |
| Separation of duties | Different roles use different users; avoid "one root for everything" |
| Group policy | Use groups to manage permission sets rather than setting permissions per user |
| Audit trail | Use sudo instead of direct root — all commands are logged |
(2) Shared Directory Permission Strategy
For team shared directories, use SGID: newly created files automatically inherit the directory's group.
# /srv/project is the shared directory
sudo chown root:developers /srv/project
sudo chmod 2775 /srv/project
# 2 = SGID (new files inherit group)
# 775 = Owner and group can read/write/execute, others can read/execute
> ⚠️ Note: The `2` in `chmod 2775` represents SGID — when SGID is set on a shared directory, any new file created there automatically inherits the directory's group (rather than the creator's primary group). This is the key mechanism for team collaboration. Without SGID, new files would belong to the creator's primary group, and other team members might not be able to modify them.
(3) /etc/skel — User Template Directory
Files in /etc/skel/ are automatically copied to a new user's home directory when their account is created. You can add custom default configurations:
# View default skel contents
ls -la /etc/skel/
# Add custom configuration for all new users
sudo tee -a /etc/skel/.bashrc << 'EOF'
# ---- Team standard configuration ----
alias ll='ls -la'
alias ..='cd ..'
export EDITOR=vim
EOF
(4) ▶ Example: Create a Complete Team User System
# Create a shared group
sudo groupadd developers
# Create accounts for three developers
for user in alice bob charlie; do
sudo useradd -m -s /bin/bash "$user"
sudo passwd "$user" # Set password interactively
sudo usermod -aG developers "$user"
echo "User $user created"
done
# Verify
grep developers /etc/group
Output:
TEXTUser alice created User bob created User charlie created developers:x:1005:alice,bob,charlie
(5) ▶ Example: Configure an SGID Shared Directory
# Create shared project directory
sudo mkdir -p /srv/project/{src,docs,scripts}
# Set the group
sudo chgrp -R developers /srv/project
# Set SGID + standard permissions
sudo chmod 2775 /srv/project
# 2 = SGID
# 7 = Owner (rwx)
# 7 = Group (rwx)
# 5 = Others (r-x)
# Test: create a file as a different user and verify group inheritance
sudo -u alice touch /srv/project/test.txt
ls -l /srv/project/test.txt
# -rw-r--r-- 1 alice developers 0 Jul 7 12:00 test.txt
# File belongs to developers group ✅
Output:
TEXT-rw-r--r-- 1 alice developers 0 Jul 7 12:00 test.txt
(6) ▶ Example: Configure Default umask
# Set a unified umask for the team (so shared files are writable by default)
echo 'umask 002' | sudo tee -a /etc/bash.bashrc
# Effect of 002:
# File: 666 - 002 = 664 (rw-rw-r--)
# Directory: 777 - 002 = 775 (rwxrwxr-x)
# This way group members can modify each other's files
> ℹ️ Note: For team collaboration, a unified umask of 002 lets group members modify each other's files. But be mindful of security — on a server shared by multiple teams, 002 may be too permissive. Recommend using SGID + 002 only in shared directories, and keeping the default 022 for user home directories.
Output:
TEXTumask 002
(7) ▶ Example: Personalized .bashrc Configuration
# Alex likes a colorful prompt
cat >> ~/.bashrc << 'EOF'
export PS1='\[\033[1;32m\]\u\[\033[0m\]:\[\033[1;34m\]\w\[\033[0m\]\$ '
alias ll='ls -lah'
EOF
source ~/.bashrc
# Bob likes it simple
cat >> ~/.bashrc << 'EOF'
export PS1='\w\$ '
alias l='ls -CF'
EOF
source ~/.bashrc
Output:
TEXTalice:~/projects$ ls -lah drwxr-x--- 2 alice developers 4096 Jul 7 10:30 .
(8) ▶ Example: sudo Privilege Management by Group
# Create a group
sudo groupadd devops
# Add Alex to the devops group (he can manage system services)
sudo usermod -aG devops charlie
# Configure sudo privileges by group
echo '%developers ALL=(ALL) ALL' | sudo tee /etc/sudoers.d/developers
echo '%devops ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/apt' | sudo tee /etc/sudoers.d/devops
> 💡 Tip: The recommended approach for sudo privilege management is the "group principle" — create groups by role (e.g., developers, devops), then create separate files under `/etc/sudoers.d/` for each group. This way, adding or removing users only requires changing group membership, without repeatedly editing sudoers files.
# Set permissions
sudo chmod 440 /etc/sudoers.d/*
Output:
TEXT%developers ALL=(ALL) ALL %devops ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/apt
(9) ▶ Comprehensive Example: Complete Multi-User Environment Deployment Script
#!/bin/bash
# setup-multi-user.sh - Set up a multi-user team development environment
set -e
echo "=== Setting up multi-user development environment ==="
# 1. Create users
TEAM_MEMBERS=("alice" "bob" "charlie")
sudo groupadd developers 2>/dev/null || true
for user in "${TEAM_MEMBERS[@]}"; do
if id "$user" &>/dev/null; then
echo "User $user already exists, skipping creation"
else
sudo useradd -m -s /bin/bash "$user"
echo "Please set password for $user:"
sudo passwd "$user"
fi
sudo usermod -aG developers "$user"
done
echo "✅ Users created"
# 2. Create shared directory
sudo mkdir -p /srv/project/{src,docs,scripts,tests}
sudo chgrp -R developers /srv/project
sudo chmod 2775 /srv/project
sudo chmod 2775 /srv/project/*/
echo "✅ Shared directory created (SGID set)"
# 3. Configure team umask
echo 'umask 002' | sudo tee -a /etc/bash.bashrc
echo "✅ Team umask configured"
# 4. Configure sudo privileges
echo '%developers ALL=(ALL) ALL' | sudo tee /etc/sudoers.d/developers
sudo chmod 440 /etc/sudoers.d/developers
echo "✅ sudo privileges configured"
# 5. Create README
cat | sudo tee /srv/project/README.md << 'EOF'
# Team Project Directory
---
## 4. Directory Structure
- src/ — Source code
- docs/ — Documentation
- scripts/ — Scripts
- tests/ — Tests
---
## 5. Rules
- umask 002, group members can modify each other's files
- Don't use root in this directory
- Confirm before using `sudo` to install software
EOF
echo "✅ README created"
echo ""
echo "=== Environment Ready ==="
echo "Users: ${TEAM_MEMBERS[*]}"
echo "Shared directory: /srv/project"
echo ""
echo "Verification:"
echo " 1. Create files as different users and check group is developers"
echo " 2. Use who to view online users"
echo " 3. Use sudo -l to view privileges"
❓ FAQ
Q: Why should shared directories have SGID? A: SGID ensures that any file or subdirectory created in a shared directory automatically inherits the parent directory's group. Without SGID, files created by a user would belong to that user's private group, and other team members wouldn't have permission to modify them. With SGID, files automatically belong to the
developersgroup.
Q: What does the
/etc/skeldirectory do? A: When you create a new user withuseradd -m, all files in/etc/skel/are automatically copied to the new user's home directory. You can put default.bashrc,.profile,.vimrcand other templates there.
Q: What happens if umask is set to 007? A: A umask of 007 means new files and directories get no permissions for "others." Files: 666-007=660 (rw-rw----), directories: 777-007=770 (rwxrwx---). Suitable for servers used exclusively by a team.
Q: What should user home directory permissions be? A: The standard is 755 (
rwxr-xr-x) — owner has full control, others can only read and execute (can cd into but can't write). For privacy, set to 750 or 700.
Q: How do I restrict a user's sudo privileges? A: Create a standalone file under
/etc/sudoers.d/that precisely specifies allowed commands:alice ALL=(ALL) /usr/bin/systemctl, /usr/bin/apt. This limits the user to sudo only systemctl and apt, nothing else.
📖 Summary
- Team user system: individual accounts + shared developers group
- SGID (
chmod g+sor numeric2xxx) makes shared directory files auto-inherit the group - umask 002 is suitable for team collaboration (group-writable)
/etc/skelsets default configuration templates for new users- sudo privilege management by group: different groups get different privilege levels
📝 Exercises
- Basic (Difficulty ⭐): Create two users
dev1anddev2, add them to theteamgroup, then create a shared directory/srv/team-projectwith SGID (2775) - Intermediate (Difficulty ⭐⭐): Create files in the shared directory as
dev1anddev2respectively, verify the files automatically belong to theteamgroup, then configuredev1to only runsudo aptandsudo systemctl(restricted commands) - Advanced (Difficulty ⭐⭐⭐): Write a script that performs all the above configuration in one go (create users, groups, directories, SGID, sudo restrictions), with argument checking and error handling