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

1. What You Will Learn


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:

BASH
# 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.

BASH
# /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:

BASH
# 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

BASH
# 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:

TEXT
User alice created
User bob created
User charlie created
developers:x:1005:alice,bob,charlie

(5) ▶ Example: Configure an SGID Shared Directory

BASH
# 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

BASH
# 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:

TEXT
umask 002

(7) ▶ Example: Personalized .bashrc Configuration

BASH
# 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:

TEXT
alice:~/projects$ ls -lah
drwxr-x--- 2 alice developers 4096 Jul  7 10:30 .

(8) ▶ Example: sudo Privilege Management by Group

BASH
# 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

BASH
#!/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 developers group.

Q: What does the /etc/skel directory do? A: When you create a new user with useradd -m, all files in /etc/skel/ are automatically copied to the new user's home directory. You can put default .bashrc, .profile, .vimrc and 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


📝 Exercises

  1. Basic (Difficulty ⭐): Create two users dev1 and dev2, add them to the team group, then create a shared directory /srv/team-project with SGID (2775)
  2. Intermediate (Difficulty ⭐⭐): Create files in the shared directory as dev1 and dev2 respectively, verify the files automatically belong to the team group, then configure dev1 to only run sudo apt and sudo systemctl (restricted commands)
  3. 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
Web-Tutorial.com

Web-Tutorial Tech Team

A team of developers maintaining programming tutorials. Each tutorial is written and reviewed by developers with expertise in that field. We work to keep our content accurate and reliable — if you spot an issue, please let us know.

100%

🙏 帮我们做得更好

我们是刚上线的编程教程站,几个人的小团队,精力有限。页面虽经检查,难免还有疏漏——链接失效、排版错乱、内容有误、语言生硬……

如果您发现了,麻烦告诉我们,我们会在收到反馈后第一时间进行修复,再次感谢您的光临 🙏