4.2 组管理与sudo授权
4.2 组管理与sudo授权
本节摘要：组是权限分配的中介单位，sudo 是受控提权的标准机制。本节从一次"五个人共用 root 密码"引发的操作纠纷讲起，覆盖组的设计模式、共享目录的完整权限方案、sudoers 的规范写法与审计、root 直登禁用，最终建立"权力有闸门、动作有记录"的治理结构。
事故现场：一次无人认领的删除
还是那家公司的故事。早期规模小，五名工程师共用 root 密码管理服务器。某个版本发布夜，一台机器的配置文件被误删，服务中断四十分钟。事后追责时尴尬了：五个人都知道密码、五个人当晚都登过机器、操作日志里只有 root 这个名字——没人认领，也没人能自证清白。最后不了了之，团队信任却裂了缝。
这次事件推动了两个变革，也正是本节的两个主角。变革一：废除 root 密码共享，每人一个账号，提权一律走 sudo——sudo 的设计初衷之一就是"每个提权动作都记录发起者"。变革二：文件协作不再靠 root 统包统揽，按团队建组、按组授权。回头看那次纠纷，技术病灶就一句话：身份不分离，审计无从谈起。
一、组：权限分配的中介
一个用户可以属于多个组，3.2 节的权限判定里属组那三位就是为协作准备的。组的模型很简单：主组每人一个（创建账号时自动建），附加组按需加入。主组决定你新建文件的默认归属，附加组决定你能访问哪些共享资源。
建组与加人：
sudo groupadd data-team sudo usermod -aG data-team zhangsan sudo usermod -aG data-team lisi id zhangsan
uid=1001(zhangsan) gid=1001(zhangsan) groups=1001(zhangsan),1010(data-team)
注意 a 加 G 的组合：a 是追加，漏掉 a 会把用户踢出其他所有附加组——这个参数坑造成过无数次"莫名丢权限"。id 输出确认 groups 列表里出现了新组。
组成员变更后，已登录的会话不会自动刷新组成员身份，需要重新登录才生效。"加了组还是没权限"的第一嫌疑就是旧会话，先开个新会话再排查。
二、共享目录：一个完整的权限方案
组的价值在共享目录兑现。需求：数据团队的成员都能读写共享区、互相不能改坏对方的文件、非团队成员不可见。方案四件套：
sudo mkdir -p /srv/data-shared sudo chown root:data-team /srv/data-shared sudo chmod 2770 /srv/data-shared
2770 这个数字用 3.2 节的知识完整拆开：特殊位的 2 是 setgid，让目录里新建文件自动继承 data-team 属组——没有它，张三建的文件属主属组都是张三个人，李四只能干瞪眼；三组权限里属主 root 全能（管理员兜底）、属组读写加执行（成员协作）、其他人无权限（团队外禁入）。
验证方案有效性，张三建文件：
sudo -u zhangsan touch /srv/data-shared/notes.md ls -l /srv/data-shared/notes.md
-rw-r--r-- 1 zhangsan data-team 0 Aug 16 23:40 notes.md
属组自动落在 data-team 上，setgid 生效，方案成立。如果想更进一步做到"互相改不坏"，在目录上再加粘滞位（特殊位变 3770），各自文件各自删改——3.2 节的粘滞位知识在这里第二次上岗。
这套方案的要义：权限跟着组走，组跟着团队走，文件归属永远不需要人肉维护。对比 777 那种"全员全权"的蛮力方案，多花的十分钟配置换来的是零维护的自运行结构。
三、sudo：权力的闸门
sudo 的字面意思是"替代用户执行"，最常用形态是提权到 root。它解决共享 root 的两个死结：密码不必共享（验证的是用户自己的密码）、动作可审计（日志记录谁在何时以什么身份执行了什么）。
最简单的授权，让 data-team 全组能执行所有管理命令：
sudo visudo
在文件里加一行：
%data-team ALL=(ALL:ALL) ALL
一行五个字段读下来：百分号开头的组名、所有主机、可以任何用户任何组身份、所有命令、需要密码。这一行是"全权委托"，适合小团队起步，但真正的治理价值在细粒度条目。比如只允许运维组执行服务管理：
%ops ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx
命令路径写全、多个命令逗号分隔、可以带参数限定——授权精确到"谁能按哪个按钮"。再进一步，发布账号只允许以应用身份执行发布脚本，其他一切拒绝。授权粒度越细，事故半径越小。
修改 sudoers 必须用 visudo 而不是直接编辑：
sudo visudo -c
/etc/sudoers: parsed OK
c 选项做语法检查。sudoers 的语法容错极低，一个笔误可能让整台机器的所有 sudo 报错，而 visudo 在保存时先检查、有问题拒绝落盘——又一次"预演思想"，这次保护的对象是提权通道本身。
sudo 的审计日志默认记录每次提权：
grep sudo /var/log/auth.log | tail -3
Aug 16 23:41:10 zhangsan : TTY=pts/0 ; PWD=/home/zhangsan ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx
谁、在哪、提权到谁、执行了什么，全部在案。开篇那次"无人认领的删除"，在这套日志面前无处遁形——治理的本质就是把"是谁干的"从悬案变成查询。
💡 关键直觉：sudo 的本质不是给人方便，是给权力装闸门。授权条目写得越细，你对系统的掌控力越强；写 ALL 固然省事，但省掉的每一个字都是未来审计时的盲区。
四、禁用 root 直登：治理的封顶工序
账号、组、sudo 就位后，最后一道工序是关闭 root 的远程通道。SSH 配置里把超级用户登录项改为禁止，重启服务生效。此后进入系统的每个人必有个人身份，提权必走 sudo，审计链条完整闭合。
验证动作要双向：个人账号密钥登录成功、root 直连被拒绝，两个都确认才算完工。改配置期间保持现有会话不退出——1.3 节锁门事故的教训在任何 SSH 配置变更时都适用。
图 4-2 从共享 root 到受控提权的治理结构
常见疑问解答
sudo 和直接 su 到 root 有什么区别
su 需要目标用户（通常是 root）的密码，等于人人都要知道 root 密码，治理问题原样保留；sudo 验证的是自己的密码、授权由配置文件集中管理、动作全部留痕。家庭机器上两者体验差不多，多人环境里只有 sudo 是合格答案。记住这个对比就够了：su 是"借他的钥匙"，sudo 是"门禁放行并登记"。
授权条目写错 root 都进不去怎么办
本地救援还在：重启进恢复模式或单用户模式，文件系统重挂为可写后修 sudoers。这是保留本地 root 控制台权限的最后一理由。预防手段就是 visudo 的语法检查加"改前留会话"的纪律，双重防线下这个窘境概率极低。
附加组加多了有什么坏处
每个附加组都是一串隐式权限，组越多你的有效权限越大、审计越难。原则：按职能进组，不按项目临时进组；半年清理一次组关系，离开职能的人及时移出。权限像衣服，合身就好，穿太多层跑不快。
文件ACL要不要用
标准权限加组设计能覆盖九成协作场景，先想组方案再想 ACL。ACL 的价值在"例外授权"：个别文件要给组外某人只读——这类精准的小例外用 ACL 很干净。原则是主结构用组、例外用 ACL，别让例外变成主结构，ACL 条目散落各处时整个权限模型会变得无法推演。
定期审查权限要做哪些事
三样：可登录账号与在职名单比对、sudoers 条目与职责比对、共享目录属组与团队名单比对。三份比对各一条命令导出清单，人工过一遍半小时。治理不是一次性工程，是季度性的例行回顾。
五、治理的度量：怎么知道做对了
治理做得好不好，不能靠感觉，要有可度量的检查项。四个指标供参考：其一，可登录账号数与在职人员数严格相等，多一个是风险，少一个是故障；其二，sudoers 里授权给个人的条目数趋近于零——个人授权意味着结构缺失，好的授权都落在组上；其三，共享目录里属组"错位"的文件占比趋近于零，setgid 体系有没有跑起来，一查便知；其四，root 直接登录的成功记录为零，任何非零都值得彻查。四个指标全部可以脚本化，纳入周期巡检。治理的成熟度不在制度文档有多厚，而在这些数字是否长期保持干净——度量让纪律从口号变成日常。
还有一个新手常问的问题值得写明：sudo 提权时输入的是谁的密码？答案是自己账号的密码，不是 root 的。这个设计正是"验证你自己"而非"验证你知道秘密"的体现——知道秘密的人可能有很多个，而"你"只有一个。也因此， sudo 会话有短时效，隔几分钟再提权要重新输入，别嫌烦，那是闸门在正常回位。
组与授权的话题合上之前，再强调一次沟通成本：治理结构的设计者要能向每个成员讲清你为什么进这个组、你的提权边界在哪。讲不清的结构没人遵守，规则一旦脱离共识就只剩形式。花半小时给团队做一次讲解，比之后无数次帮我看看为什么我没权限的打断便宜得多。治理是人的系统，别忘了它最终靠人运转。
最后补一个跨章呼应：本节的授权设计与第 2 章的"预演"思想在精神上完全一致——预演是给破坏性命令装观察窗，授权粒度是给破坏性身份装围栏，两者都在把"事后追责"前移为"事前约束"。安全工程的全部智慧几乎都可以归结为这一句话：把关口修在事前，别把力气花在事后。你在这本教程里一次次遇到这个思想，不是巧合，是工程世界的底层规律。
本节要点回顾
- 组是权限的中介：主组定默认归属，附加组开共享资源，共享在文件层不在身份层
- setgid 是共享目录的灵魂：新建文件自动继承属组，零维护的协作结构
- 加组记得带追加选项：漏掉它会把用户踢出其他组，经典参数坑
- sudoers 写得越细 审计盲区越小：路径写全、命令限定、visudo 落盘
- sudo 日志是治理的账本：谁 何时 提权到谁 干了什么，一查便知
- root 直登禁用是封顶工序：身份分离完成，审计链条闭合
第 4 章完。最后一章讲软件包管理——依赖解析、版本冲突、离线安装，运维进阶的最后一座山。
最后给一个 sudo 授权的实践模板，供起步时参考。运维组：允许全部命令（他们本来就要管机器）；开发组：允许以应用账号身份执行发布与日志查看两类命令；数据组：允许只读类命令（查询与状态查看）。三个组的授权粒度依次收紧，对应职责边界。起步不必完美，先让"每个人都能干活但谁都不越界"成立，再随事故与审计反馈逐步收紧。授权体系是活的东西，半年调一次很正常，一次定终身反而说明没人看审计日志。
授权审计还有个实操细节：sudoers 的组织方式。机器一多，授权条目散落在各机器的本地文件里，审计等于逐台翻。规范做法是按团队拆分成独立的授权片段文件，放进专门的配置目录（发行版都支持该目录下的片段自动加载），每个团队一个文件、文件头注释负责人与用途。这样审计时按团队抽查即可，新增授权也有明确的落点。授权管理的进化方向是把片段纳入配置管理工具统一分发——第 4.1 节末尾提过的那条路，在这里再次交汇：账号、组、授权，最终都走向"清单描述加自动执行"的形态。