Linux学习日志：权限管理综合实战

项目概述

本次学习围绕Linux用户与权限管理展开，包含两个核心实验：

实验一：SGID与团队共享目录
验证在目录上设置SGID后，新建文件自动继承目录属组，实现团队协作。
实验二：目录权限与用户组诊断实战
模拟普通用户无法写入目录的问题，通过排查用户组、目录权限和访问控制逻辑，定位问题根源并给出解决方案。

通过两个实验，深入理解Linux权限验证顺序、特殊权限位（SGID）以及组成员身份与目录权限的配合关系。
环境信息
项目 配置
操作系统 CentOS 7
IP地址 192.168.209.129
当前用户 sdz (UID 1000, wheel组)
SSH客户端 MobaXterm
实验时间 2026-03-30 ~ 2026-03-31
实验用户总览
用户名 UID GID 附加组 密码 用途
dev1 1002 1003 devops 123456 SGID实验：文件创建者
dev2 1003 1004 devops 123456 SGID实验：协作读写者
lab_user 1001 1001 wheel → root, wheel 123456 权限诊断实验：模拟问题用户
实验一：SGID与团队共享目录验证

注释：SGID（Set Group ID） 是 Linux 中的特殊权限位，用于可执行文件或目录：

文件：执行该文件的进程会继承文件所属组的权限，而非启动者的组（例如 /bin/passwd 依赖此特性修改 /etc/shadow）。
目录：在该目录下新建的文件/子目录会自动继承目录的所属组，常用于团队协作目录。

设置命令：chmod g+s 文件名/目录名（例如 chmod 2755 dir，数字 2 代表 SGID）。
查看：ls -l 显示组权限位的 x 变为 s（如 drwxrwsr-x）。
任务目标

创建共享目录 /data/share，设置SGID位。
验证不同用户在目录下创建的文件是否自动继承目录的属组（devops）。
验证组成员对彼此文件的读写权限。

任务拆分

用户与组准备
创建共享目录并设置SGID
SGID效果验证（dev1创建文件）
协作读写验证（dev2操作）

任务过程
步骤1：用户与组准备

执行命令：

查看当前身份

id
groups

创建组

sudo groupadd devops

创建用户（带家目录，指定附加组）

sudo useradd -m -G devops dev1
sudo useradd -m -G devops dev2
sudo useradd -m -G wheel lab_user

设置密码（批量方式）

echo "dev1:123456" | sudo chpasswd
echo "dev2:123456" | sudo chpasswd
echo "lab_user:123456" | sudo chpasswd

验证用户

id dev1
id dev2
id lab_user

查看组信息

grep devops /etc/group
grep wheel /etc/group

指令讲解：

sudo groupadd devops：创建专用组 devops，用于共享目录的属组。
sudo useradd -m -G devops dev1：创建用户并附加到 devops 组。-m 创建家目录，-G 指定附加组列表。
echo "dev1:123456" | sudo chpasswd：通过管道为 dev1 设置密码，避免交互。
grep devops /etc/group：确认组存在且成员正确。

步骤2：创建共享目录并设置SGID

执行命令：

创建共享目录

sudo mkdir -p /data/share

设置所有者和属组

sudo chown root:devops /data/share

设置权限（SGID）

sudo chmod 2775 /data/share

验证权限

ls -ld /data/share

预期输出：

drwxrwsr-x. 2 root devops 6 3月 30 20:36 /data/share

指令讲解：

mkdir -p：确保父目录 /data 存在，若不存在则一并创建。
chown root:devops：属主设为 root，属组设为 devops。
chmod 2775：数字 2 表示设置SGID位；775 表示属主、属组拥有读写执行权限，其他人拥有读执行权限。
SGID作用：当目录设置了SGID，新建文件会自动继承目录的属组（devops），而非用户的主组。

步骤3：SGID效果验证（dev1创建文件）

执行命令：

切换至dev1（登录式切换）

su - dev1

进入共享目录

cd /data/share

创建测试文件

touch dev1-test.txt

查看文件详细信息

ls -l

退出dev1

exit

预期输出：

-rw-rw-r--. 1 dev1 devops 0 3月 30 21:12 dev1-test.txt

关键点：文件的属组是 devops，而不是 dev1 的主组，证明SGID生效。
步骤4：协作读写验证（dev2操作）

执行命令：

切换至dev2

su - dev2

进入共享目录

cd /data/share

读取dev1创建的文件

cat dev1-test.txt

追加内容到文件（测试写入权限）

echo "modified" >> dev1-test.txt

再次查看文件信息

ls -l

退出dev2

exit

预期结果：

cat 成功，因为 dev2 属于 devops 组，拥有读权限。
追加内容成功，因为属组有写权限。
文件大小增大，属组仍为 devops。

结论：SGID机制实现了团队成员在共享目录中无缝协作，彼此创建的文件均属于同一组，可读写。
执行流程图

graph TD
A[开始实验一] --> B[创建组 devops
创建用户 dev1, dev2]
B --> C[创建目录 /data/share
chown root:devops]
C --> D[设置权限 2775
启用SGID]
D --> E[验证目录权限
drwxrwsr-x]

subgraph SGID效果验证
    E --> F[切换至 dev1<br>su - dev1]
    F --> G[cd /data/share]
    G --> H[touch dev1-test.txt]
    H --> I[ls -l 显示属组 devops]
    I --> J[退出 dev1]
end

subgraph 协作验证
    J --> K[切换至 dev2<br>su - dev2]
    K --> L[读取 dev1-test.txt<br>cat 成功]
    L --> M[追加内容<br>echo >> 成功]
    M --> N[ls -l 文件仍属 devops]
    N --> O[退出 dev2]
end

O --> P[实验一完成<br>SGID实现团队共享属组]

实验二：目录权限与用户组诊断实战
任务目标

模拟一个普通用户 lab_user 无法写入 /opt/project 目录的问题，通过逐步排查（检查用户组、目录权限、访问控制逻辑），定位根本原因并给出解决方案。
任务拆分

环境准备：创建目录 /opt/project，设置权限 750。
初次尝试：lab_user 尝试写入，观察失败。
用户身份诊断：检查 lab_user 的组成员关系。
权限修复尝试：
    将 lab_user 添加到 root 组，观察效果。
    使用 sudo 修正目录属组与权限。
最终诊断与原理分析。

任务过程
步骤1：环境准备与初步权限设定

执行命令：

以 sdz 身份执行

sudo mkdir /opt/project
sudo chmod 750 /opt/project
ls -ld /opt/project

输出：

drwxr-x---. 2 root root 6 3月 31 10:58 /opt/project

指令讲解：

chmod 750：权限分解：
    属主 root：7 (rwx)
    属组 root：5 (r-x) → 注意：没有写入权限
    其他用户：0 (---)

步骤2：初次尝试访问与诊断

执行命令：

su - lab_user
touch /opt/project/test.txt
groups
exit

输出：

touch: cannot touch ‘/opt/project/test.txt’: Permission denied
lab_user wheel

诊断：lab_user 当前属于 wheel 组，但不属于 root 组。而目录 /opt/project 的属组是 root，且权限为 r-x，因此用户只能进入和读取，无法写入。
步骤3：修复尝试——修改用户附加组

执行命令：

sudo usermod -aG root lab_user
su - lab_user
groups
id lab_user
touch /opt/project/test.txt

输出：

groups=1001(lab_user),0(root),10(wheel)
uid=1001(lab_user) gid=1001(lab_user) groups=1001(lab_user),0(root),10(wheel)
touch: cannot touch ‘/opt/project/test.txt’: Permission denied

关键发现：即使 lab_user 加入了 root 组，依然无法写入。说明问题不在于用户是否属于 root 组，而在于目录属组权限本身没有写权限。
步骤4：确认与重置目录权限

执行命令：

ls -ld /opt/project
sudo chown root:root /opt/project
sudo chmod 750 /opt/project
ls -ld /opt/project

输出：

drwxr-x---. 2 root root 6 3月 31 10:58 /opt/project

分析：目录属组为 root，权限为 r-x，所以即使 lab_user 是 root 组的成员，也只能获得 r-x 权限（可读可执行，但不可写）。
步骤5：最终诊断与原理分析

执行命令：

su - lab_user
groups
touch /opt/project/test.txt

结果：依然 Permission denied。

结论：
lab_user 无法写入 /opt/project 的根本原因是：目录属组 root 的权限为 r-x，缺少写入权限。用户虽然属于 root 组，但只能获得该组权限，无法覆盖缺少的写权限。

解决方案（任选其一）：

将目录属组权限改为 rwx：sudo chmod 770 /opt/project
改变目录属组为 lab_user 所在的某个组，并赋予写权限。

执行流程图

graph TD
A[开始实验二] --> B[创建目录 /opt/project
权限 750]
B --> C[lab_user 尝试写入
touch 失败]

C --> D{lab_user 是否属于 root 组?}
D -->|否| E[usermod -aG root lab_user]
D -->|是| F[检查目录权限]
E --> F

F --> G[目录权限 drwxr-x---<br>属组 root 权限 r-x]
G --> H[lab_user 属于 root 组<br>匹配属组权限]
H --> I[获得权限 r-x<br>可以 cd 和 ls，但不能写]
I --> J[touch 再次失败]

J --> K[结论：属组缺少写权限]
K --> L[解决方案：chmod 770<br>或更改属组]

style E fill:#f9f,stroke:#333
style G fill:#ff9,stroke:#333
style K fill:#ccf,stroke:#333

知识延伸与总结
权限验证逻辑回顾

Linux 访问权限验证严格遵循以下顺序：

若进程的有效用户 ID 等于文件属主 ID，则应用属主权限。
否则，若有效组 ID 或任一附加组 ID 等于文件属组 ID，则应用属组权限。
否则，应用其他用户权限。

在实验二中，lab_user 命中了第二条，因此应用了属组 r-x 权限，而非其他用户的 --- 权限，所以能进入目录但无法写入。
特殊权限位总结
权限位 数字 文件作用 目录作用
SUID 4 运行文件时获得属主权限 （通常无意义）
SGID 2 运行文件时获得属组权限 新建文件/目录继承目录属组
Sticky 1 （通常无意义） 限制删除：仅所有者/root可删
最佳实践建议

团队协作目录：使用 chmod 2770 + chown root:team，并配合 Sticky bit（+t）防止误删。
用户组管理：修改组后需重新登录（exit 再 su -）才能使新组生效。
权限排查步骤：
    确认当前用户身份：id、groups。
    确认目标文件/目录的权限：ls -ld。
    对照权限验证逻辑，分析用户匹配的是属主、属组还是其他。
    根据需求调整权限或用户组。

⚠️ 风险提示：

    避免将普通用户加入 root 组（GID 0），因为 root 组通常拥有对系统关键文件的写权限，可能引发安全风险。
    在生产环境使用 usermod -G 时务必添加 -a 参数，否则会覆盖用户原有的所有附加组，导致权限丢失。

通过本次综合实战，不仅掌握了 SGID 在团队协作中的应用，还通过一个实际排查案例深化了对权限验证逻辑的理解。