权限与 ACL 出问题时的排查顺序:从现象到根因
SUID 只对可执行文件生效,root 的 SUID 程序是提权的主要目标
正确的第一步是分类:起不来、连不上、跑得慢,三条路完全不同。
先说结论
先分三类,再由外向内查:网络、进程、配置、依赖、资源。
- 先确认现象能复现,且能描述清楚
- 由外向内:端口、进程、配置、依赖、资源
- 读第一条错误,不是最后一条
- 改一个变量,验证一次,别一次改五处
- 留下记录:现象、假设、验证、结论
第一类:起不来
先看进程在不在,再看它为什么退出:SUID 只对可执行文件生效,root 的 SUID 程序是提权的主要目标。
- 查看服务状态与最近日志(不是全部日志)
- 确认端口是否被占用、权限是否足够
- 确认配置文件语法(多数服务支持 test 模式)
- 确认依赖的数据目录存在且可写
第二类:连不上
按「本机、网络、代理、应用」四层查:
| 层级 | 验证方式 | 典型原因 |
|---|---|---|
| 本机 | 本机 curl / telnet 端口 | 没监听、只听 127.0.0.1 |
| 网络 | 从另一台机器访问 | 防火墙、安全组、VLAN |
| 代理 | 检查反代配置与证书 | 路径、超时、头部大小 |
| 应用 | 看访问日志与错误日志 | 鉴权、限流、连接池耗尽 |
第三类:跑得慢
ACL 的 mask 参与权限计算,chmod 改组权限时可能顺手把 mask 改掉。
慢的问题先分清是「等」还是「算」:CPU 高是算,CPU 低但延迟高是等(IO、锁、网络)。

这个服务的高频故障点
同类的坑基本集中在这些位置:
- 目录没有 x 位就进不去,只有 r 位时能看到文件名却读不到属性
- SUID 只对可执行文件生效,root 的 SUID 程序是提权的主要目标
- Sticky 位(/tmp 的 1777)保证只有属主能删自己的文件
别做的事
只加 ACL 不设默认 ACL,新建文件又回到 644
用 chmod -R 755 递归改家目录,把 SSH 私钥变成全员可读
一次改多个参数,会让下一次故障更难查。
把结论写下来
排查记录不是给别人看的,是给三个月后的自己看的。Sticky 位(/tmp 的 1777)保证只有属主能删自己的文件。
还有几处容易忽略的
都是小地方,但出问题时往往就卡在这里。
- umask 022 让新文件是 644、新目录是 755;改成 027 则同组只读
- mv 跨文件系统会重建文件,属主和 ACL 可能变成执行者的
- 把网站目录设成 777 图省事,任意脚本都能写进 webshell
排障能力不是知道更多命令,是知道先查什么。
评论 (3)
排查顺序那段直接抄进值班手册了。
版本差异要强调,我照着做结果参数名全变了。
备份没验证过等于没有,这条我认。
发表评论