linux_实训2
文章目录
- 一、问题场景说明（Scenario）
- 二、传统权限方式的分析（不使用 SGID）
- 1. 用户与组准备
- 2. 创建开发目录
- 3. 使用传统权限进行尝试
- 4. 实际测试结果（问题出现）
- alex 创建文件
- arod 尝试访问
- 5. 传统权限的根本缺陷
- 三、SGID 的作用与解决方案
- 1. 什么是 SGID（目录上的含义）
- 2. 启用 SGID 并设置最终权限
- 3. 再次测试（成功）
- alex 创建文件
- arod 访问文件
- 四、为什么项目目录“必须”使用 SGID？
- 1. 不使用 SGID 的后果
- 2. 使用 SGID 的优势
- 3. 管理员角度的最佳实践
- 五、总结一句话
一、问题场景说明（Scenario）
系统中存在两个用户账号：
- alex
- arod
特点如下：
- 两个账号各自有自己的主组
- 同时都属于 project 这个附加组
- 两人需要共同开发
/srv/ahome目录下的项目 - 其他用户不允许查看或访问该目录
管理员目标：
- 让 alex 和 arod都能在该目录中创建、修改彼此的文件
- 确保目录和文件的访问权限严格受控
- 使用
chmod、chgrp等命令完成配置
二、传统权限方式的分析（不使用 SGID）
1. 用户与组准备
groupaddprojectuseradd-G project alexuseradd-G project arod确认账号属性：
idalexuid=1008(alex)gid=1012(alex)groups=1012(alex),1011(project)idaroduid=1009(arod)gid=1013(arod)groups=1013(arod),1011(project)说明：
- 主组：alex / arod
- 共同附加组：project
2. 创建开发目录
mkdir/srv/ahome ll -d /srv/ahome drwxr-xr-x2root root4096Sep2922:36 /srv/ahome此时目录：
- 属主：root
- 属组：root
- 权限：755（其他人可读）
这显然不符合需求。
3. 使用传统权限进行尝试
管理员通常会想到：
- 把目录属组改成 project
- 给组写权限
- 禁止其他人访问
chgrpproject /srv/ahomechmod770/srv/ahome此时目录权限为：
drwxrwx--- root project /srv/ahome看起来很合理：
- alex / arod 都在 project 组
- 其他用户无法访问
4. 实际测试结果（问题出现）
alex 创建文件
su- alexcd/srv/ahometouchabcd ll abcd结果类似：
-rw-rw-r--1alex alex0Sep2922:46 abcd⚠️问题关键在这里：
- 文件属主：alex
- 文件属组：alex（主组）
- 并不是 project
arod 尝试访问
su- arodcd/srv/ahome ll abcd分析：
- arod ≠ alex
- abcd 的属组是 alex
- arod不属于 alex 组
- 因此 arod 被当成other
👉 即使目录权限正确，文件权限已经破坏协作
👉 arod无法修改 alex 创建的文件
5. 传统权限的根本缺陷
Linux 默认规则：
新文件的属组 = 创建者的“主组”
这意味着：
- 多人协作目录中
- 文件属组会被“分裂”
- 权限管理复杂、不可控
- 管理员需要频繁
chgrp
👉传统权限机制不适合多人项目开发目录
三、SGID 的作用与解决方案
1. 什么是 SGID（目录上的含义）
当SGID 设置在目录上时：
该目录中创建的所有新文件和子目录，自动继承目录的属组
⚠️ 注意：
- 不改变属主
- 只控制属组继承
2. 启用 SGID 并设置最终权限
chmod2770/srv/ahome权限含义拆解：
| 位 | 含义 |
|---|---|
| 2 | SGID |
| 7 | owner：rwx |
| 7 | group：rwx |
| 0 | other：— |
查看结果：
ll -d /srv/ahome drwxrws---2root project4096Sep2922:46 /srv/ahomes表示：SGID 已生效
3. 再次测试（成功）
alex 创建文件
su- alexcd/srv/ahometouch1234ll1234结果：
-rw-rw-r--1alex project0Sep2922:531234✔ 文件属组：project
arod 访问文件
- arod 属于 project
- umask = 002
- 具有组写权限
👉双方可以互相修改文件
四、为什么项目目录“必须”使用 SGID？
1. 不使用 SGID 的后果
- 文件属组混乱
- 成员之间互相无法修改
- 管理员需要频繁手动修正
- 项目规模越大，问题越严重
2. 使用 SGID 的优势
| 优点 | 说明 |
|---|---|
| 自动继承组 | 文件永远属于 project |
| 权限一致 | 不会因主组不同而失效 |
| 管理成本低 | 无需频繁 chgrp |
| 安全性高 | other 永久无权访问 |
| 符合协作模型 | 适合源码、脚本、配置文件 |
3. 管理员角度的最佳实践
多人开发目录标准配置：
chgrpproject /srv/ahomechmod2770/srv/ahome配合：
umask002这是Linux 项目开发环境的经典方案。
五、总结一句话
在多人协作的项目目录中，仅依靠传统权限无法保证文件属组一致，必须通过在目录上设置 SGID，使新建文件自动继承项目组，从而确保组内成员能够互相修改文件，同时避免权限混乱。这是系统管理员配置开发环境的标准做法。