Linux 系统权限配置详解：从 chmod 到 ACL、sudo 与 capabilities

🎯

这篇文章的目标不是让你背命令，而是建立一个判断框架：看到 ls -l 输出时知道谁能做什么；配置目录时知道该用 chmod、chown、组、ACL、sudo 还是 capabilities；出问题时能按顺序定位。

1. 先建立全局模型：Linux 权限到底在管什么 2. 用户、组和进程身份 2.1 UID、GID 数字分别代表什么 2.2 RUID、EUID、SUID、FSUID：为什么 SUID 能影响提权判断 3. 读懂 ls -l：一行输出拆开看 4. 数字权限：为什么 755、644、600 这么常见 5. chmod：修改权限 6. chown 与 chgrp：修改属主和属组 7. umask：新文件默认权限从哪里来 8. 特殊权限位：setuid、setgid、sticky bit 8.1 chmod 4777 到底是什么意思 8.2 s 和 S 的区别 8.3 setuid：让程序以文件属主身份运行 8.4 setgid：文件和目录含义不同 8.5 sticky bit：公共可写目录防止互删 8.6 四位权限速查表 9. ACL：当 owner/group/others 不够用 ACL mask 是什么 10. sudo：允许用户执行特定管理动作 11. Linux capabilities：把 root 权限拆成小块 12. 授权渗透测试里的提权枚举视角 12.1 当前身份和上下文 12.2 枚举 SUID 文件 12.3 枚举 SGID 文件和目录 12.4 查找 world-writable 文件和目录 12.5 检查可写 PATH 目录 12.6 检查 sudo 规则 12.7 检查 capabilities 12.8 检查 ACL 和隐藏授权 12.9 权限提权检查脑图 12.10 记录报告时怎么写 13. 常见配置场景场景 A：个人 SSH 私钥权限场景 B：Web 站点静态文件场景 C：团队共享目录场景 D：给临时审计用户只读权限场景 E：让普通服务监听 80 端口 14. 排错流程：Permission denied 时怎么查 15. 安全建议清单 16. 一套可复用的权限设计流程 17. 速查命令参考资料

1. 先建立全局模型：Linux 权限到底在管什么

Linux 权限的核心问题只有一句话：某个进程能不能对某个对象执行某个动作。

这里有三个关键词：

进程：真正访问文件的是进程，不是“人”。你登录 shell 后运行 cat、vim、nginx，这些程序进程会带着你的 UID、GID 和补充组去请求内核。

对象：通常是文件、目录、设备文件、socket，也可以是进程、网络端口、内核接口等。

动作：读、写、执行、进入目录、删除、改属主、绑定低端口、重启服务等。

传统 Unix 权限主要处理文件系统上的读写执行；如果规则不够细，就引入 ACL；如果任务是“允许某个命令以管理员身份运行”，通常用 sudo；如果只想给程序一小块 root 能力，可能用 Linux capabilities。

💡

新手最容易混淆的一点：root 不是“更高级的普通用户”，而是传统 Unix 模型里的超级用户。很多权限检查对 root 会放行，所以日常配置时应该少用 root、少给 777，把权限给到具体用户、组或服务进程。

2. 用户、组和进程身份

Linux 里每个用户有一个 UID，每个组有一个 GID。文件系统权限会把访问者分成三类：

user / owner / u：文件属主。

group / g：文件属组，以及属于这个组的用户。

others / o：既不是属主、也不在属组里的其他用户。

常用查看命令：

典型输出：

读法：alice 的主组是 alice，同时还属于 wheel 和 developers。假设一个目录属组是 developers，且组权限有写入位，那么 alice 通常可以写。

2.1 UID、GID 数字分别代表什么

UID 是 User ID，GID 是 Group ID。Linux 内核做权限判断时主要看数字，不是看用户名字符串。用户名 root、alice 只是方便人类阅读的名字，最终会映射到 /etc/passwd、/etc/group 或 NSS 后端中的数字 ID。

最重要的数字是：

数字	常见名字	含义	安全意义
`UID 0`	`root`	超级用户	传统 Unix 权限模型里拥有最高权限，很多权限检查会对 UID 0 放行
`GID 0`	`root` 组	root 组	不等于 root 用户，但属于敏感组；具体权限取决于文件属组和 sudo/系统配置
`1-999`	系统用户/服务用户	常见发行版里多用于 daemon、bin、www-data、mysql、nginx 等系统账号	范围因发行版和 `/etc/login.defs` 而异，不要死背，只看实际配置
`1000+`	普通登录用户	很多 Linux 发行版默认第一个普通用户从 1000 开始	渗透测试里拿到 `uid=1000` 一般表示普通用户权限
`65534`	`nobody` / `nogroup`	低权限匿名用户	常用于 NFS、匿名服务或降权场景，通常权限很低

查看系统实际范围：

典型 /etc/passwd 行长这样：

字段含义：

这里要注意：

root:x:0:0 表示 root 用户的 UID 是 0，主组 GID 也是 0。

www-data:x:33:33 表示 Web 服务账号常见是低编号系统用户，但不是 root。

/usr/sbin/nologin 表示通常不能直接登录 shell，但服务进程仍然可以用这个身份运行。

2.2 RUID、EUID、SUID、FSUID：为什么 SUID 能影响提权判断

日常看 id 时通常只关心 uid=1000(alice)，但进程内部其实有几类 UID。理解它们，才能理解 SUID 程序为什么特殊。

名称	全称	作用	例子
RUID	Real UID	真实用户 ID，表示进程最初由谁启动	alice 执行程序，RUID 通常是 1000
EUID	Effective UID	有效用户 ID，内核做大多数权限检查时主要看它	alice 执行 root-owned SUID 程序时，EUID 可能变成 0
SUID	Saved set-user-ID	保存的用户 ID，允许程序在真实权限和特权身份之间切换	某些程序会临时降权，再在需要时恢复特权
FSUID	File-system UID	Linux 用于文件系统权限检查的 UID	一般和 EUID 一致，网络文件系统或特殊程序里可能单独调整

GID 也有类似概念：真实 GID、有效 GID、保存 GID、文件系统 GID。SGID 程序影响的就是有效 GID。

用一句话记：RUID 说明“谁启动了我”，EUID 说明“我现在按谁的权限办事”。

SUID 提权判断的核心就是看：一个普通用户启动程序后，程序的 EUID 是否变成更高权限身份，尤其是 EUID=0。如果 EUID 是 0，程序内部任何不安全的文件写入、命令调用、库加载、环境变量处理，都可能变成高危问题。

可以在授权测试或靶场中用这些方式观察当前身份：

/proc/<pid>/status 里的 Uid 一行通常有 4 个数字，依次对应 Real、Effective、Saved、Filesystem UID：

如果某个进程显示类似：

含义就是：真实启动者是 UID 1000，但有效 UID、保存 UID、文件系统 UID 是 0。此时它正在以 root 权限通过关键权限检查。

🔎

渗透测试里看到 uid=0(root) 基本表示已经拿到 root 级别权限；看到 euid=0(root) 则说明当前进程在权限检查上按 root 处理，即使真实启动用户不是 root。SUID 程序的风险判断重点通常看 EUID。

常用用户与组管理命令：

⚠️

usermod -G developers alice 会把 alice 的补充组替换成 developers；如果你本来想“追加一个组”，要用 -aG。很多人就是在这里把自己的 sudo 组弄没了。

3. 读懂 `ls -l`：一行输出拆开看

第一列最重要，比如 drwxr-x---：

权限字符含义：

字符	对普通文件	对目录	容易误解的地方
r	读取文件内容	列出目录里的文件名	目录只有 r 没有 x 时，经常看得见名字但进不去、也读不了详情
w	修改文件内容	在目录内创建、删除、重命名条目	能不能删除文件主要看父目录 w 和 x，不只看文件本身
x	执行文件	进入目录、穿过路径	目录 x 更像“通行权”，没有它路径后面的文件也访问不到

举个非常重要的目录例子：

4. 数字权限：为什么 755、644、600 这么常见

数字权限是八进制，每一位都是 r、w、x 的加法：

r = 4

w = 2

x = 1

所以：

7 = 4 + 2 + 1 = rwx

6 = 4 + 2 = rw-

5 = 4 + 1 = r-x

4 = 4 = r--

0 = ---

三位数字分别对应 owner、group、others：

权限	展开	常见用途	说明
600	rw-------	私钥、个人配置	只有属主可读写
644	rw-r--r--	普通网页、配置模板、静态文件	属主可写，其他人只读
700	rwx------	个人脚本目录、私有目录	只有属主可进入和操作
755	rwxr-xr-x	普通目录、可执行程序	其他人可进入或执行，不可写
750	rwxr-x---	团队目录、服务目录	属主全权，组可读可进入，其他人无权限
770	rwxrwx---	团队共享写目录	属主和组都能写，其他人无权限
777	rwxrwxrwx	几乎不要用	所有人可写，风险很高

5. `chmod`：修改权限

chmod 支持两种主要写法：数字法和符号法。

数字法直接设置完整权限：

符号法适合“增减某一类权限”：

X 很适合目录树：目录需要 x 才能进入，但普通文本文件通常不该被加执行权限。

🧭

判断该用数字还是符号：如果你要把权限改成一个明确终态，用 chmod 750 dir；如果你只想补一个权限，比如“给组加写”，用 chmod g+w dir 更不容易误伤已有设置。

6. `chown` 与 `chgrp`：修改属主和属组

文件属主和属组决定了 u、g、o 三套权限里哪一套会被命中。

常见写法：

使用 -R 时要非常小心，尤其是带变量或通配符时。先用 ls、find 或 --dry-run 类似思路确认范围。chown -R 改错系统目录会把服务、sudo、SSH 权限弄坏。

7. `umask`：新文件默认权限从哪里来

你创建新文件时，并不是每次都手动 chmod。系统会从基础权限里减去 umask：

普通文件基础通常按 666 计算，因为新文件默认不该自动可执行。

目录基础通常按 777 计算，因为目录没有 x 就不能进入。

常见 umask：

umask	新文件常见权限	新目录常见权限	适用场景
022	644	755	常见默认：别人可读，不可写
027	640	750	服务或团队服务器：其他人无权限
077	600	700	私密环境：只有自己可访问
002	664	775	协作组目录：组成员可写

查看和临时设置：

永久设置位置和发行版有关，常见位置包括：

用户 shell：~/.bashrc、~/.profile、~/.zshrc

全局 shell：/etc/profile、/etc/bash.bashrc

PAM 登录：/etc/login.defs、/etc/pam.d/*

systemd 服务：unit 文件里使用 UMask=0027

systemd 服务例子：

8. 特殊权限位：setuid、setgid、sticky bit

普通权限常见写成 3 位，例如 755。但你也会看到 4755、2755、1777、4777 这种 4 位写法。第 1 位不是 owner 权限，而是特殊权限位。

四位八进制可以这样拆：

特殊位本身也按加法计算：

特殊位数字	名称	符号法	主要含义	常见显示
4	setuid	`u+s`	可执行文件运行时临时使用文件属主的有效 UID	owner 的 x 位显示 `s` 或 `S`
2	setgid	`g+s`	文件运行时使用文件属组的有效 GID；目录中新建内容继承目录属组	group 的 x 位显示 `s` 或 `S`
1	sticky	`+t`	目录内只有文件属主、目录属主或 root 能删除/改名文件	others 的 x 位显示 `t` 或 `T`

特殊位可以相加：

chmod 4755 file = setuid + 755

chmod 2755 dir = setgid + 755

chmod 1777 dir = sticky + 777

chmod 6777 file = setuid + setgid + 777

chmod 7777 file = setuid + setgid + sticky + 777

🧠

读四位权限时先拆成“特殊位 + 普通三位”。4777 不是“比 777 多一点点”，而是“setuid + 所有人可读写执行”。如果属主是 root，这通常是极高风险配置。

8.1 `chmod 4777` 到底是什么意思

假设有一个 root 拥有的可执行文件：

你可能会看到：

逐位解释：

文件类型：- 表示普通文件。

owner 权限：rws，属主 root 可读、可写、可执行，并且 setuid 生效。

group 权限：rwx，属组可读、可写、可执行。

others 权限：rwx，所有其他用户也可读、可写、可执行。

setuid 效果：普通用户执行这个文件时，进程的有效 UID 会变成文件属主，也就是 root。

所以，如果 /opt/demo/tool 是 root 拥有，chmod 4777 /opt/demo/tool 的风险是双重的：

任何人都能执行它，并可能以 root 有效身份运行它。

任何人都能修改它。 这意味着其他用户可能替换或篡改这个文件内容；一旦再执行，就可能把恶意逻辑放进一个 setuid root 程序里。

这也是为什么渗透测试里看到 root-owned、SUID、world-writable 的文件要立刻标为高危。

🚨

4777 放在 root 拥有的可执行文件上，通常比单纯 777 更危险。777 是“所有人能改”；4777 是“所有人能改，并且执行时可能带着属主身份”。在真实系统里几乎没有合理理由这样配置。

8.2 `s` 和 `S` 的区别

ls -l 中特殊位会覆盖原来的 x 位置，所以你会看到小写或大写：

显示	位置	含义	例子
`s`	owner x 位	setuid 已设置，并且 owner 有执行权限	`-rwsr-xr-x`
`S`	owner x 位	setuid 已设置，但 owner 没有执行权限	`-rwSr-xr-x`
`s`	group x 位	setgid 已设置，并且 group 有执行权限	`-rwxr-sr-x`
`S`	group x 位	setgid 已设置，但 group 没有执行权限	`-rwxr-Sr-x`
`t`	others x 位	sticky 已设置，并且 others 有执行权限	`drwxrwxrwt`
`T`	others x 位	sticky 已设置，但 others 没有执行权限	`drwxrwxrwT`

大写通常意味着“特殊位在，但执行位不在”，经常是配置不完整或误配。

8.3 setuid：让程序以文件属主身份运行

setuid 只对可执行文件有关键意义。典型例子是 passwd。普通用户需要改自己的密码，但又不能直接写系统密码数据库，于是 passwd 程序本身由 root 拥有，并带 setuid 位，在程序内部做严格检查后完成必要写入。

查看：

设置与取消：

渗透测试视角：setuid 本身不是漏洞，但 setuid + 不安全程序行为 可能形成提权路径。例如程序会调用外部命令、加载用户可控配置、写入用户可控路径、跟随符号链接、没有清理环境变量等。测试时要先确认是否在授权范围内，再做低风险验证和记录。

🚨

不要随便给脚本或不可信程序加 setuid root。很多脚本语言、动态库加载、环境变量、临时文件处理都可能导致提权漏洞。生产环境里，能用 sudo 精确授权或 capabilities 解决，就不要滥用 setuid。

8.4 setgid：文件和目录含义不同

setgid 放在可执行文件上时，程序运行时会临时使用文件属组的有效 GID。它不像 setuid root 那么常见，但如果属组能访问敏感文件，也可能造成越权读取或写入。

setgid 放在目录上更常见：目录中新建的文件和子目录会继承该目录属组。团队共享目录经常这样配置。

结果：

这表示：

2：setgid。

770：owner 和 group 可读写进入，others 无权限。

s 出现在 group 的 x 位置：目录启用了 setgid，且组有进入权限。

渗透测试视角：如果某个敏感目录是 setgid 且组可写，要检查自己是否属于该组、目录内脚本是否被高权限任务执行、是否存在可控文件被服务读取或执行的情况。

8.5 sticky bit：公共可写目录防止互删

/tmp 通常是 1777：所有人都能写，但不能随便删除别人的文件。

逐位拆解 1777：

1：sticky bit。

t：sticky 生效，others 也有执行/进入权限。

如果一个公共可写目录没有 sticky bit，例如 0777，用户之间就可能互相删除或替换文件。对于 /tmp、上传缓存目录、构建临时目录，这都是需要关注的问题。

8.6 四位权限速查表

命令	展开理解	`ls -l` 典型形态	风险判断
`chmod 0755 file`	无特殊位，owner 可写，其他人可执行/读取	`-rwxr-xr-x`	常见可执行文件权限
`chmod 4755 file`	setuid + 755	`-rwsr-xr-x`	若属主为 root，需要审计程序行为
`chmod 4777 file`	setuid + 777	`-rwsrwxrwx`	极高风险：所有人可改且可能以属主身份运行
`chmod 2755 file`	setgid + 755	`-rwxr-sr-x`	关注属组能访问什么敏感资源
`chmod 2770 dir`	setgid + 770	`drwxrws---`	团队共享目录常见配置
`chmod 1777 dir`	sticky + 777	`drwxrwxrwt`	公共临时目录常见配置
`chmod 7777 file`	setuid + setgid + sticky + 777	`-rwsrwsrwt`	通常是严重误配，需立即调查

9. ACL：当 owner/group/others 不够用

传统权限只有一个属主、一个属组、一个 others。现实中经常遇到这种需求：目录属于项目组，但临时给某个外部用户只读权限；或者某个用户需要写入，而不想把他加进整个项目组。这时用 ACL。

安装工具：

查看 ACL：

给用户 alice 读写执行：

给组 auditors 只读和进入目录：

递归给已有内容：

设置默认 ACL，让新建文件也继承规则：

删除某条 ACL：

删除所有扩展 ACL，保留基础权限：

ACL mask 是什么

ACL 里有一个非常容易忽略的 mask。它是 named user、named group 和 owning group 的最大有效权限上限。

这里 alice 看起来有 rwx，但 mask 只有 rw，所以最终有效权限没有 x。很多“明明 setfacl 给了权限还是不行”的问题都出在 mask。

修复方式：

🧪

文件权限后面如果有 +，例如 -rw-rw-r--+，说明存在 ACL。看到 + 就应该用 getfacl，不要只看 ls -l。

10. sudo：允许用户执行特定管理动作

文件权限解决“谁能读写文件”。sudo 解决“谁能以另一个用户身份执行命令”，最常见是以 root 身份执行管理命令。

不要直接编辑 /etc/sudoers，使用：

更推荐在 /etc/sudoers.d/ 新建小文件：

例子 1：允许 deploy 用户重启 nginx：

例子 2：允许 developers 组执行部署脚本，但不要给整个 root shell：

例子 3：免密码要慎用：

🔒

sudo 配置的安全原则：授权具体命令，不授权通配的 shell；尽量避免 NOPASSWD；命令路径写绝对路径；脚本本身必须只有 root 可写，否则用户可以改脚本内容再 sudo 执行。

检查命令路径：

11. Linux capabilities：把 root 权限拆成小块

传统模型里 root 权限太大。Linux capabilities 把部分 root 能力拆开，例如：

CAP_NET_BIND_SERVICE：允许绑定小于 1024 的特权端口。

CAP_NET_RAW：允许使用 raw socket，常见于 ping 一类程序。

CAP_CHOWN：允许改变文件 UID/GID。

CAP_DAC_OVERRIDE：绕过部分文件读写执行权限检查，权限很大，应谨慎。

查看文件 capabilities：

给程序允许绑定 80 端口，而不是让它以 root 运行：

移除：

systemd 服务也能配置能力边界：

这比“整个服务用 root 跑”更安全。但 capabilities 仍然是高级权限机制，给错能力同样危险。

12. 授权渗透测试里的提权枚举视角

✅

本节只用于已获授权的渗透测试、靶场、CTF 或内部安全审计。目标是理解“为什么权限误配会成为提权入口”，并形成检查清单；不要在未授权系统上执行枚举或验证。

Linux 提权不是只靠某个“神奇命令”。更稳定的思路是：先确认当前身份，再枚举哪些地方把更高权限暴露给了当前用户或当前进程。

12.1 当前身份和上下文

重点看：

当前用户是否在 sudo、wheel、adm、docker、lxd、disk、www-data、业务部署组等敏感组。

当前 shell 是交互式登录用户，还是 Web 服务、计划任务、容器内用户。

sudo -l 是否允许你以 root 或其他用户运行某些命令。

12.2 枚举 SUID 文件

SUID 文件是提权检查重点，因为它们可能让普通用户运行时获得文件属主的有效身份。

读法：

-perm -4000：查找设置了 setuid 位的文件。

-type f：只看普通文件。

-ls：打印权限、属主、大小、路径等信息。

2>/dev/null：忽略无权限访问目录产生的错误输出。

看到结果后不要急着“利用”，先判断：

属主是谁？root-owned 的 SUID 文件最敏感，因为普通用户执行时 EUID 可能变成 0。

权限是否异常？例如 -rwsrwxrwx、-rwsrwxr-x、位于用户可写目录下。

路径是否异常？系统常见 SUID 通常在 /usr/bin、/bin、/usr/sbin；业务目录、临时目录、home 目录里的 SUID 更值得关注。

程序是否标准组件？未知二进制要记录哈希、路径、属主、时间戳，必要时离线分析。

运行时身份是否变化？在授权靶场中可观察进程的 Real UID 与 Effective UID，确认是否出现 RUID=普通用户、EUID=0 这种特权执行状态。

常见基线里会出现一些正常 SUID 程序，例如 passwd、su、sudo、mount、umount、pkexec。不同发行版不完全相同，所以判断重点不是“有 SUID 就一定有洞”，而是“是否不该有、是否可写、是否行为危险、是否版本存在已知问题”。

12.3 枚举 SGID 文件和目录

SGID 风险通常来自两类：

SGID 可执行文件：执行时获得文件属组权限，如果属组能读写敏感资源，就可能越权。

SGID 可写目录：新建内容继承目录属组，如果高权限任务会读取或执行目录内文件，就可能产生链式风险。

12.4 查找 world-writable 文件和目录

“所有人可写”不等于一定能提权，但它经常是提权链条中的一环。

重点关注：

world-writable 文件是否属于 root 或服务用户。

world-writable 目录是否缺少 sticky bit。

目录里是否有脚本、配置、插件、日志轮转文件、备份文件会被高权限进程读取。

可写目录是否出现在高权限用户的 PATH 中。

判断 sticky bit：

如果看到公共目录是 drwxrwxrwx 而不是 drwxrwxrwt，要记录为风险点。

12.5 检查可写 PATH 目录

如果某个高权限脚本执行命令时没有写绝对路径，例如写 tar 而不是 /bin/tar，并且它的 PATH 前面包含当前用户可写目录，就可能被路径劫持。

枚举当前 PATH：

逐个检查目录权限：

提权判断点：

高权限脚本是否使用相对命令名。

脚本是否由 root、cron、systemd、sudo 规则执行。

这里的核心不是“PATH 本身危险”，而是“高权限执行 + 相对命令 + 可写 PATH”组合危险。

12.6 检查 sudo 规则

重点看：

是否有 NOPASSWD。

是否能以 root 运行编辑器、解释器、归档工具、包管理器、服务管理器等。

命令是否带通配符，例如 /usr/bin/vim *、/bin/chown *。

可 sudo 执行的脚本是否可被当前用户或所在组写入。

风险判断：sudo 规则本身是授权机制，但如果授权命令能读写任意文件、执行子命令、加载插件、调用 shell，可能变成提权入口。可以参考 GTFOBins 了解常见 Unix 程序在 sudo、SUID、capabilities 等上下文中的风险分类，但实际验证必须受授权范围约束。

12.7 检查 capabilities

重点关注：

cap_setuid+ep、cap_setgid+ep：可能直接影响身份切换。

cap_dac_read_search+ep、cap_dac_override+ep：可能绕过传统文件权限读取或写入。

cap_sys_admin+ep：范围极大，接近“半个 root”，通常高危。

cap_net_bind_service+ep：常用于绑定 80/443 低端口，通常风险较低，但仍要看程序是否可写、是否可信。

判断顺序：先看文件路径和属主，再看 capability 类型，最后看该文件是否可被当前用户修改或替换。

12.8 检查 ACL 和隐藏授权

如果文件权限后有 +，说明存在 ACL：

渗透测试中要特别注意：

当前用户是否通过 ACL 获得了本不该有的写权限。

default ACL 是否让新文件继承过宽权限。

mask 是否让表面权限和实际权限不一致。

12.9 权限提权检查脑图

12.10 记录报告时怎么写

发现权限类提权风险时，报告里至少写清楚：

当前权限：ls -l、stat、getfacl、getcap 输出。

影响主体：哪些用户、组、服务进程能访问。

风险原因：例如 root-owned SUID 且 world-writable、sudo 规则过宽、capability 过大。

验证方式：只写授权范围内的低风险验证，不贴越界利用步骤。

修复建议：移除特殊位、收紧权限、改属主属组、限制 sudo、移除 capability、增加 sticky bit、调整 ACL。

13. 常见配置场景

场景 A：个人 SSH 私钥权限

SSH 对私钥权限非常严格。推荐：

如果属主错了：

场景 B：Web 站点静态文件

目标：nginx 能读，普通用户不能随便写。

如果部署用户需要写入，可以让部署用户属于某个组，再给组写权限，不要直接 chmod -R 777：

场景 C：团队共享目录

目标：project 组成员都能读写，其他人无权限，新文件自动归 project 组。

验证：

场景 D：给临时审计用户只读权限

不想把 auditor 加进 project 组，可以用 ACL：

审计结束后移除：

场景 E：让普通服务监听 80 端口

方案一：用反向代理，把应用监听 127.0.0.1:8080，nginx 监听 80。

方案二：给二进制 capabilities：

方案三：systemd 限定 capabilities：

不要为了监听 80 端口就让整个应用长期以 root 运行。

14. 排错流程：Permission denied 时怎么查

常用排错命令：

几个典型症状：

文件权限看起来对，但仍不能访问：检查父目录有没有 x，使用 namei -l。

ACL 给了 rwx 但实际没有执行：检查 getfacl 里的 mask。

nginx 读不了文件：确认 nginx worker 进程实际用户，常见是 www-data、nginx、apache。

普通用户能写目录却删不了别人文件：检查 sticky bit，例如 /tmp 的 t。

root 也改不了文件：检查 lsattr 是否有 immutable 属性 i，需要 chattr -i。

服务创建文件权限不符合预期：检查 shell umask 或 systemd UMask=。

15. 安全建议清单

不要用 chmod -R 777 解决问题。它通常只是把问题藏起来，并制造更大的安全洞。

目录常用 755、750、770；文件常用 644、640、660；秘密文件常用 600。

团队协作优先使用组和 setgid 目录，而不是把所有人都加 sudo。

临时、个别用户授权优先用 ACL，任务结束要清理。

服务进程尽量使用专用低权限用户，例如 www-data、nginx、myapp。

sudo 只授权具体命令，脚本必须 root 拥有且不可被普通用户写。

用 capabilities 替代“整个程序以 root 运行”时，要只给必要 capability，并记录原因。

递归命令前先确认路径：pwd、ls、find ... -maxdepth，避免变量为空导致改错目录。

配置完要验证：用目标用户实际执行一次，或者 sudo -u username command 测试。

16. 一套可复用的权限设计流程

明确对象：要保护的是文件、目录、服务、端口，还是管理命令？

明确主体：谁需要访问？人类用户、服务用户、某个组，还是一次性审计账号？

明确动作：只读、读写、执行、进入目录、删除、重启服务、绑定端口？

选机制：普通 chmod/chown 能解决就不用 ACL；ACL 能解决就不用 sudo；sudo 能限定命令就不用 root shell。

设默认：目录协作用 setgid 和 default ACL；服务用 UMask=。

验证：用实际用户身份测试，不只看配置。

留痕：重要权限变更写入文档或变更记录。

17. 速查命令

参考资料

Debian manpage: chmod(1)

Debian manpage: chown(1)

GNU Coreutils manual: Numeric Modes

man7.org: setfacl(1)

man7.org: umask(2)

man7.org: capabilities(7)

Red Hat Enterprise Linux 9: Managing file system permissions

Red Hat Enterprise Linux 8: Managing ACLs

ArchWiki: File permissions and attributes

GTFOBins：用于授权测试中理解常见 Unix 程序在 sudo、SUID、capabilities 等上下文里的风险分类