Linux UID/EUID与SUID/SGID权限机制全解

盯着ls -l输出发呆的经历，大概每个跟 Linux 打交道的人都有一两次。文件明明是自己建的，cat能读，vim保存时却提示只读；或者某个程序跑起来之后whoami说你是 root，但你敲echo $UID还是 1000；再或者给脚本加了执行权限和小 s，跑起来却一点特权都没拿到。这类现象九成不是系统坏了，而是把 UID、GID、EUID、EGID、SUID、SGID 这六个词混成了同一个概念。

我用下来最大的感受是：这六个标识里，前四个是进程身上的属性，后两个是文件身上的属性，它们唯一的关系是"文件上的开关决定了进程属性怎么变"。把这层本来是两类东西的关系搞混，后面的 setuid 调用、权限提升、容器挂载排查全都会打结。这篇就把这六个标识掰开揉碎讲一遍，从数据结构讲到实际调用，从单个进程讲到多用户协作目录，中间穿插我自己踩过的坑。适合刚接触 Linux 权限体系、被 setuid 折腾过、或者要交付一个需要临时提权的程序的人看。基础部分我会讲得慢一点，有经验的朋友可以直接跳到第三、四章。

1. 六个标识的职责边界，先分清"谁是谁"

1.1 UID 和 GID：账户系统里的编号，不是权限本身

内核眼里根本不存在"用户名"这个东西。/etc/passwd第一列那些好记的名字，只是给人和工具看的索引，内核判定身份时永远只认那个数字。你可以把/etc/passwd里的用户名改成任意字符串，只要第三列的 UID 不变，这个账户对文件的访问权限一点都不会变。反过来，如果两个账户的 UID 都写成 0，它们在系统里就是同一个人，虽然用户名不同，但都能拿到完整特权——这也是为什么安全基线检查里会专门去扫重复的 UID 0 账户。

GID 的结构稍微复杂一点。一个进程只归属于一个主组，也就是id -g打印出来的那个数字；同时它还可以挂在一批附加组下面，用id -G能看到完整列表。权限检查的时候，主组合附加组是平等参与的，只要文件的属组出现在这个集合里，就能按组权限位判断。附加组的数量有上限，具体值跟内核编译参数和内嵌的组 ID 缓存有关，跑大批量授权的时候偶尔会撞到这个天花板，表现出来就是"明明把这个用户加进组了，他就是访问不了"，id一看发现附加组被截断了。

这里顺带提一个排查习惯：用名字看权限容易吃亏。ls -l显示属主名字，如果系统接了统一认证、存在重名或者缓存不一致，看到的名字可能跟真实 UID 对不上。ls -n强制显示数字，stat -c '%u %g %a' 文件名直接给出 UID、GID 和八进制权限位，这两个命令在排错时比ls -l靠谱得多。

1.2 EUID 和 EGID：内核判权限时真正看的那张"工作证"

真正决定一次open()、read()、kill()能不能过的，是EUID（有效用户 ID），不是 UID。这层关系很多人嘴上知道，真排查时还是忘。举个最能体现差异的例子：whoami命令内部取的是 EUID，而id -un取的是真实 UID。一个设置了 SUID 位、属主为 root 的程序，如果在里面调起一个 shell，那个 shell 的whoami会告诉你 root，可echo $UID还是你自己的号。两个输出打架，不是哪一个错了，是它们问的根本不是同一个字段。

Linux 还额外维护了一对fsuid / fsgid，专门给文件系统访问检查用。绝大多数时候它俩就等于 EUID / EGID，但只要程序调用了setfsuid()，就能在不动 EUID 的前提下单独改变文件访问身份。这个设计主要是给网络文件系统服务端那类程序用的——它们需要在处理某个请求的短短几行代码里，临时以客户端用户的身份判断一次权限，处理完立刻切回来，不想污染整个进程的有效身份。日常写业务代码基本碰不到，但读源码时会遇到，知道有这么个东西就行。

想知道一个运行中的进程到底处于什么身份，最直接的办法是读/proc/PID/status，里面Uid:这一行有四个数字，依次是真实、有效、保存设置、文件系统，Gid:同理。四个数字全一样，说明这个进程没有借用任何身份；第一个和第二个不一样，就是已经提权或者降权了。这条命令我在排查现场用得比什么都多。

1.3 SUID 和 SGID：它们不是身份，是写在文件上的两个开关

这一节是全文的地基。SUID 和 SGID 不是进程属性，是文件权限位里的两个比特，八进制表示里分别是 4000 和 2000。chmod 4755里的 4 就是 SUID，chmod 2755里的 2 就是 SGID。它们平时安静地躺在 inode 里，只有当这个文件被execve()执行的那一刻，才会触发一段特殊逻辑，去改写新进程的 EUID 或 EGID。

命名上的混乱正是理解困难的来源：UID、EUID 是"身份"，SUID 里那个 S 是 "Set user ID" 的缩写，字面意思是"设置用户 ID"，指的是"执行时把有效用户 ID 设成文件属主"。它描述的是一个动作，不是一个身份值。同理 SGID 是 "Set group ID"，执行时把有效组 ID 设成文件属组。所以准确的读法是：SUID / SGID 是动词，UID / EUID 是名词。

提示：后面还会出现一个"保存的设置用户 ID"（saved set-user-ID），它确实是一个身份值，跟 SUID 这个权限位不是一回事。名字撞车是历史原因，读到那里别混淆。

把这条分清之后，很多疑问自然就散了：为什么chmod u+s加在一个普通脚本上完全没用（因为脚本的执行路径根本不经过那段特殊逻辑）；为什么 SUID 只能由属主或特权用户设置（因为它在授权"以我的身份运行"）；为什么挂载选项里有个nosuid（因为它是挂在文件系统层面的一个总闸）。

2. 进程里其实存着三套身份

2.1 真实、有效、保存设置：三套并存的意义

一个 Linux 进程在身份这件事上不是一个数字，而是一组。用户维度上有三个：真实用户 ID、有效用户 ID、保存的设置用户 ID；组维度上对称地也有三个。加上前面提到的 fsuid / fsgid，/proc里那一行四个数字就是这么来的。

三套并存不是为了炫技。真实身份回答"我是谁派生的"，用于记账、审计、信号发送权限判断；有效身份回答"我现在以什么身份干活"，用于绝大多数权限检查；保存的设置身份回答"我原来是谁，还能不能回去"。三种问题对应三个字段，缺一个都会让提权程序陷入两难：要么提上去下不来，要么下来了上不去。

举个具体的场景。一个属主是 root、带 SUID 位的备份工具，由普通用户 A 启动。启动瞬间，进程的真实 UID 是 A，有效 UID 变成 0，保存的设置 UID 也变成 0。工具在真正读那些只有 root 能读的文件时，用的是有效 UID 0，畅通无阻。读完准备把结果写到 A 的家目录，这时候如果还顶着 root 身份写，生成的文件属主就是 root，A 自己反而改不了。所以它必须临时把有效 UID 切回 A，写完再切回 0 继续读别的。这个"切回去"的能力，全靠保存的设置 UID 记着 A 原来是谁——更准确地说，是靠它记着还能切成哪些值。

2.2 fork 全盘继承，exec 才是有条件改写

身份在进程生命周期里的流转规则，用一句话概括：fork()原样复制，execve()有条件重写。

fork()出来的子进程，真实、有效、保存三套身份跟父进程一模一样，一个比特都不差。所以在提权程序里 fork 一个子进程去干脏活，子进程同样顶着提升后的身份，这一点经常被忽略，导致本该降权的操作没降。

execve()才是真正会发生变化的点，而且变化规则很讲究。执行一个普通文件（没有 SUID / SGID 位），三套身份全部保持原样，新程序继承旧进程的身份。执行一个带 SUID 位的文件，如果调用方有权限，内核会把新进程的有效 UID 设为文件属主，保存的设置 UID 也设为文件属主，真实 UID 保持不变。SGID 位同理，改写的是有效组 ID 和保存的设置组 ID。

这里有个容易被忽略的推论：SUID 的效果是每次 exec 都重新触发的。一个 setuid 程序如果在内部又 exec 了自己，新一轮的身份提升照样发生。这也是为什么有些守护进程会反复 exec 自己来做"软重启"，身份状态一直很稳定。

反过来，execve()的时候如果没有 SUID 位，有效 UID 保持原值——这意味着一个已经降权的进程，exec 一个新程序不会自动把身份提回来。想恢复只能靠保存的设置 UID，而那个值如果已经被覆盖掉了，就彻底回不去了。第 3 章讲setuid()陷阱的时候会再回到这一点。

2.3 没有"保存设置身份"，提权程序就无法安全降权

假设没有保存的设置 UID 这一层，一个 SUID 程序启动后是什么局面：真实 UID 是 A，有效 UID 是 0。它想临时降权去写 A 的文件，于是调用seteuid(A)，有效 UID 变成 A。这时候它想再升回 0 继续干活——怎么升？没有任何字段记着"我曾经是 0"，内核只能拒绝。程序从此被锁死在普通用户身份上，后半段的特权操作全部失败。

有了保存的设置 UID，规则就变成：非特权进程只能把自己的有效 UID 切换到真实 UID 或保存的设置 UID 这两个值之一。程序降权后，保存的设置 UID 仍然是 0，所以随时可以切回去。这条规则的关键在于它不是"任意切换"——普通进程不能凭空调成一个自己从没拥有过的身份，否则整个权限模型就崩了。

而一旦进程以特权身份调用setuid()（注意不是seteuid()），内核会把三套身份全部改成目标值，保存的设置 UID 也就跟着被覆盖了。这就是"永久降权"的实现方式，也是很多安全加固建议里那句"尽早永久放弃特权"的技术依据。第 3 章会把这几条路径逐条拆开。

3. setuid 系列四个接口的选择逻辑

3.1 setuid 在特权进程和非特权进程下的两种语义

setuid(uid_t uid)这个函数的名字最容易让人以为它只是"设置一下当前用户"，实际上它的行为完全取决于调用者当前有没有特权，是两套截然不同的语义。

特权进程（拥有CAP_SETUID能力，通常就是 EUID 为 0 的进程）调用setuid(x)，内核会把真实、有效、保存设置三个 UID 一起改成 x。这是"永久切换身份"的语义，改完就回不去了。很多守护进程启动流程的最后一步就是setuid(运行用户)，从此彻底放弃 root，后面就算被攻破也拿不到特权，这是标准的加固手法。

非特权进程调用setuid(x)，行为收窄成：如果 x 等于当前的真实 UID 或者保存的设置 UID，就把有效 UID 改成 x；否则返回EPERM。也就是说它只能在"自己本来是谁"和"自己借来的身份"之间来回切，不能凭空变成别人。

这个双语义是大量 bug 的源头。我见过最常见的写法错误是这样的：一个 SUID 程序启动后想临时降权处理用户输入，写了setuid(getuid())。作者的意图是"切回普通用户"，结果因为进程此刻是特权状态，这一句直接把三套身份全改成了普通用户，后面所有需要特权的操作立刻EPERM。正确的写法应该是seteuid(getuid())——只动有效身份，保存的设置身份留着当退路。

注意：判断该用哪个函数，先问自己一句"我还需要变回特权身份吗"。需要，就用seteuid或setresuid；不需要，用setuid一次性放弃，反而更安全。

3.2 setreuid 的隐式副作用容易被忽略

setreuid(ruid, euid)允许同时设置真实和有效两个 UID，传 -1 表示该项不变。它比setuid灵活，能表达"交换真实和有效身份"这种操作，早期很多需要来回切换身份的程序都用它。

麻烦在于它有一个隐式副作用：当有效 UID 被改变时，保存的设置 UID 会被悄悄设成新的有效 UID。也就是说，setreuid(-1, 某个值)不只是改了有效身份，还顺手把"退路"给覆盖了。如果你原本指望着降权之后还能靠保存的设置 UID 切回特权，这一下就断了。

这个行为在不同标准里的描述有细微出入，实际表现又以具体实现为准，所以它在可移植性上一直是个雷区。我的建议很直接：新代码不要用setreuid，它的坑不比它带来的灵活性少。真要精确控制三个字段，用setresuid。

3.3 setresuid 与"能降不能升"的边界

setresuid(ruid, euid, suid)是最直白的一个：三个参数分别对应三套身份，传 -1 表示保持不变。语义清晰，没有隐式副作用，Linux 上直接对应同名系统调用，是精细控制身份时的首选。

它的边界条件值得记牢。特权进程可以给三个字段设任意值；非特权进程则要求每一个被设置的值，都必须落在此刻的真实 UID、有效 UID、保存的设置 UID 这三个值构成的集合里。换句话说，你可以把自己降下去，但绝不能升上来——除非那个"更高的身份"本来就在你的保存设置 UID 里躺着。

这条规则解释了一个经典的安全设计：SUID 程序在开始处理不可信输入之前，先setresuid(getuid(), getuid(), 保存的特权值)——把真实和有效都降到普通用户，只把保存的设置 UID 留作特权退路。这样即使后面的代码被输入漏洞攻破，攻击者拿到的也只是一个普通用户身份；程序处理完不可信输入，再setresuid(-1, 特权值, -1)把有效身份提回来做真正的特权操作。危险窗口被压缩到最短。

3.4 一段可以自己编译验证的代码

嘴上说十遍不如跑一遍。下面这段程序不干别的，就是把当前的三套身份打印出来，你可以用它观察各种组合下的实际效果。

#include <stdio.h> #include <unistd.h> #include <sys/types.h> static void show(const char *tag) { printf("[%s] real=%d effective=%d\n", tag, getuid(), geteuid()); fflush(stdout); } int main(void) { show("启动时"); uid_t ruid = getuid(); uid_t euid = geteuid(); /* 只改有效身份，保存的设置身份保留 */ if (seteuid(ruid) == 0) show("seteuid 降权后"); /* 再切回原有效身份 */ if (seteuid(euid) == 0) show("seteuid 恢复后"); /* 一次性放弃，三套身份全改 */ if (setuid(ruid) == 0) show("setuid 永久降权后"); /* 这一步在永久降权后应当失败 */ if (seteuid(euid) != 0) printf("尝试恢复失败，符合预期\n"); return 0; }

编译和观察的完整流程：

gcc -Wall -o idprobe idprobe.c ./idprobe # 普通身份下跑，三套身份一致 sudo chown root idprobe sudo chmod 4755 idprobe ./idprobe # SUID 生效，启动时 effective 变 0 sudo chmod 0755 idprobe # 去掉 SUID 再跑一次对比

跑完你会在最后一步看到"尝试恢复失败"，这就是永久降权的直接证据：保存的设置 UID 已经被setuid()覆盖成普通用户，seteuid(euid)想升回 0 时被内核拒绝。把setuid那一段删掉再跑，恢复就能成功。这几行输出比任何文档都直观。

顺手再补一个观察手段，程序跑起来的时候另开一个终端，ps -eo pid,ruid,euid,suid,cmd | grep idprobe，或者直接读cat /proc/$(pgrep idprobe)/status | grep -E '^Uid|^Gid'，四列数字一秒看清当前状态。这比在代码里反复打日志快得多。

4. SUID 位：从 ls 里的那个 s 到 execve 的判定路径

4.1 大写 S、脚本上的 SUID、以及为什么无效

ls -l输出里属主执行位那个位置，正常是x，设了 SUID 就变成s。这里有个细节特别值得记住：如果显示的是大写 S，意思是 SUID 位设了，但执行位没设。这种情况下 SUID 不产生任何效果——文件根本不能被执行，那段特殊逻辑自然也就不会跑。看到大写 S 的时候，先chmod +x补执行位，别急着怀疑别的地方。

然后是那个坑了无数人的问题：给 shell 脚本加 SUID 到底有没有用。答案是在 Linux 上没有用，而且这不是 bug。内核处理#!开头的脚本时，实际执行的是解释器程序（/bin/bash、/usr/bin/python3之类），脚本本身只是作为参数传进去。如果让脚本的 SUID 生效，那意味着要按脚本属主的身份去运行整个解释器，而解释器可以被脚本内容任意操纵，等于把特权身份交给了一段可编辑的文本，风险不可控。所以内核的处理方式很干脆：直接忽略脚本上的 SUID 和 SGID 位。

chmod u+s backup.sh之后跑起来没反应，不是权限没生效，是这条路本来就不通。想实现"普通用户执行某脚本时临时获得特定权限"，可选的方案有：写一个几十行的 C 包装程序，在里面setuid后exec解释器；用sudo配一条精确到命令和参数的规则；或者给解释器二进制本身加文件能力。三个方案的安全性依次递增，适用场景不同，第 7 章会展开对比。

顺带说一个同源的问题：/etc/ld.so.preload这类全局预加载机制在 SUID 程序里是被主动忽略的，原因也是同一个——不能让控制"加载什么代码"的人同时控制"以什么身份运行"。

4.2 AT_SECURE 和 no_new_privs 这两道闸

execve()执行带 SUID 的文件时，内核除了改身份，还会在传给新程序的辅助向量里塞一个标记AT_SECURE，值为 1。动态链接器看到这个值，就会主动忽略一批环境变量：LD_PRELOAD、LD_LIBRARY_PATH、LD_AUDIT等等。没有这道闸，攻击者只需要设一个环境变量，就能把自己的库注入到 SUID 程序里，在特权身份下执行任意代码，整套机制形同虚设。

这道闸也解释了另一个常见困惑："为什么我在 SUID 程序里设的LD_LIBRARY_PATH没起作用"。不是设置失败，是被安全机制主动丢弃了。调试阶段想临时绕过可以用LD_DEBUG观察加载过程，但正经交付时不要试图在这上面做文章。

第二道闸是no_new_privs。进程可以通过prctl(PR_SET_NO_NEW_PRIVS, 1)给自己打上这个标记，从此以后任何 execve 都不能带来额外的权限——SUID 位被忽略，SGID 位被忽略，文件能力也不生效。这个标记是单向的，一旦设上就没法撤销。容器运行时普遍会在启动用户进程前设上它，防止容器内通过 SUID 程序做权限提升。排查"容器里 SUID 程序怎么不生效"的时候，这是第一个要检查的点，cat /proc/PID/status | grep NoNewPrivs，值为 1 就说明闸已经关上了。

4.3 上线前必须过的检查清单

SUID 程序是攻击面最集中的一类程序，一旦有漏洞，危害直接放大到文件属主的权限级别。我在交付这类程序之前会按下面这张表逐项过一遍，缺一项都不放行。

再补两条实操层面的经验。第一，上线后定期扫一遍 SUID 文件清单：find / -xdev -perm -4000 -type f -print 2>/dev/null，把结果存成基线，之后每次比对差异。多出来的那个文件，往往就是问题所在。第二，nosuid挂载选项要用在该用的地方：用户家目录、/tmp、/var/tmp、外部挂载的存储，这些位置本来就不该存在合法的 SUID 程序，直接挂载时加nosuid关掉这条通道，成本低收益高。

5. SGID 的两个战场：文件借用组身份，目录继承组归属

5.1 文件上的 SUID：组身份借用

文件上的 SGID 位（02000）跟 SUID 是对称的：执行时把新进程的有效组 ID 设为文件的属组，保存的设置组 ID 也一并设成这个值，真实组 ID 不动。除此之外，某些实现下还会把文件的属组加进进程的附加组集合里，具体行为跟内核版本和文件系统有关，不值得依赖。

它的实际用途比 SUID 窄得多。典型场景是"某个程序需要访问一组文件，这组文件都归某个专用组所有，属主不一定是这个程序的属主"。这时候给程序设 SGID，把程序属组定为那个专用组，就能在不提升到 root 的前提下拿到组访问权限。相比 SUID 提升到属主身份，SGID 提升的粒度更细，危害面也更小，能用 SGID 解决就尽量别用 SUID。

还有一个特殊情形值得一提：可执行文件如果同时设了 SUID 和 SGID，两者会同时生效。查权限的时候别只看s的位置，ls -l里属主和属组执行位上的两个s要都看一眼。

5.2 目录上的 SGID：团队协作目录的地基

目录上的 SGID 是完全不同的另一套逻辑，而且跟"执行"没有半点关系——它控制的是新建文件的属组继承。

一个目录被chmod g+s之后，在这个目录里新建的文件和子目录，其属组会自动继承目录的属组，而不是创建者的主组。子目录还会额外继承 SGID 位，所以整棵子树的组归属都保持一致。这个特性在多人协作的场景里几乎是必需品：几个人共享一个项目目录，无论谁在里面建文件，属组都统一成项目组，其他人才能按组权限访问。

配置一套能真正工作的协作目录，是这样的：

sudo groupadd proj sudo usermod -aG proj alice sudo usermod -aG proj bob sudo mkdir -p /srv/proj sudo chgrp proj /srv/proj sudo chmod 2775 /srv/proj

到这里很多人就收工了，然后发现同事还是写不进去。原因在umask。新建文件的初始权限是0666 & ~umask，新建目录是0777 & ~umask。默认 umask 022 下，新文件权限是 0644，组位是只读；新目录是 0755，组位没有写权限。SGID 只解决了"属组是谁"，没解决"属组能不能写"。

解决办法有两个方向。一是把协作目录里相关用户的 umask 调成 002，但 umask 是进程级设置，改起来影响面太大，容易顾此失彼。二是用默认 ACL，只对这一个目录生效：

sudo setfacl -d -m g:proj:rwx /srv/proj sudo setfacl -d -m o::- /srv/proj

-d表示默认 ACL，只影响在这个目录里新建的文件和子目录，已有的不受影响。getfacl /srv/proj能看到以default:开头的几条规则。这套组合我用了很久，效果是新建文件自动带项目组读写权限，其他人一律无权限，比调 umask 精确得多。

提示：chmod作用在带 ACL 的目录上时，会重写 mask 条目，可能把 ACL 的权限"截断"。改完chmod之后记得getfacl复查一眼。

5.3 粘滞位解决的是另一个问题

粘滞位（sticky bit，八进制 1000）经常跟 SGID 一起被提到，因为它俩都写在目录上，但解决的问题完全不同：它管的是删除，不是创建。

一个目录只要对某用户有写权限，该用户就能删除目录里任何文件——哪怕那个文件是别人的、他自己连读都读不了。这是很多人没意识到的一条规则：删除权限由父目录的写权限决定，不由文件本身的权限决定。共享目录如果放开写权限又不加限制，任何人都能删掉别人的成果。

给目录设上粘滞位chmod +t，规则就变成：只有文件所有者、目录所有者、特权用户能删除或重命名目录里的文件。/tmp的经典权限 1777 就是这个组合：所有人可读写（新建），但只有自己能删自己的。

共享项目目录要不要加粘滞位，取决于协作模式。如果团队成员地位平等、互相删改是正常操作，不加；如果是不特定多用户共享的临时空间，一定要加。回答"同组同事能不能删掉我建的文件"，答案就是粘滞位的开关。

6. 三个身份错乱的现场，按排查链路走一遍

6.1 现场一：服务创建的文件属主是 root

现象：某个后台服务以专用账户运行，配置里明明写了运行用户，可它生成的日志和上传文件属主都是 root，专用账户自己都改不了，下次启动直接报错。

排查顺序是这样的。先确认服务进程的实际身份：ps -eo pid,ruid,euid,suid,cmd | grep 服务名，如果三个数字都是 0，说明降权根本没发生，问题在服务管理器的配置层。再去看配置：现代 Linux 的服务管理器用User=和Group=指定运行身份，但要注意ExecStartPre=里那些前置命令仍然以 root 执行，因为它们发生在切换身份之前。如果前置命令创建了目录或文件，属主就是 root，后面切换到专用用户的主进程自然写不进去。

修复方案有两条路。一是把创建目录的工作交给服务管理器做，用RuntimeDirectory=、StateDirectory=、LogsDirectory=这类声明式配置，它们会自动创建目录并把属主设成配置的运行用户，权限还能用RuntimeDirectoryMode=精确控制。二是在ExecStartPre里显式chown一把，但这要求你在同一条命令里把用户和组都写全，否则可能只改了用户没改组。

还有一类更隐蔽的情况：服务已经正确降权，但它调用的某个子进程是 SUID 的，或者通过某个中间层提了权，最终写出来的文件属主就不是预期的那个。这种时候要顺着进程树往上查，/proc/PID/status里的Uid四列数字一个都不能漏看。

6.2 现场二：容器挂载目录写不进去

现象：容器里跑得好好的应用，一旦把宿主机目录挂进去就报权限错误，容器内看那个目录属主是个陌生的大数字，或者干脆显示nobody。

根因通常在用户命名空间上。容器内看到的 UID 是一套映射后的编号，跟宿主机上的不是一回事。映射关系在/proc/PID/uid_map里，三列分别是容器内起始 UID、宿主机起始 UID、映射长度。如果配置成容器内 UID 0 映射到宿主机 UID 100000，那容器里的 root 在宿主机眼里就是一个普通的、权限很低的用户，挂载进来的目录如果属主是宿主机的真实用户，容器内当然写不进去。

排查链路：先cat /proc/$(容器主进程PID)/uid_map确认映射范围；再stat -c '%u %g' 宿主机目录拿到真实属主；两头一对就知道差在哪儿。常见解法有三个——把宿主机目录的属主改成映射后的那个 UID（推荐，最干净）；在容器启动配置里显式指定--user让容器直接以映射后的身份运行；或者在镜像里调整应用运行用户的 UID，让它跟宿主机对齐。

第三种做法在团队里推的时候要小心，因为它把镜像和宿主机环境绑死了，换一台机器 UID 对不上又要重来。我自己的偏好是第一条：宿主机侧把目录属主一次性设好，容器里该用什么用户就用什么用户，两边通过 UID 数字对齐，不依赖名字。

另外提醒一句，如果用到了--privileged之类放开全部权限的启动参数，上面这些映射问题确实会"消失"，但代价是整个隔离层失效，不值得为了省事这么干。正确的做法是用文件能力把需要的那一项单独给出去。

6.3 现场三：共享存储上 SUID 程序失效与属主错乱

现象：一个在本地运行正常的 SUID 程序，放到网络共享存储上之后，普通用户执行时完全拿不到特权，whoami还是自己。

网络文件系统对 SUID 的处理有两个独立的影响因素。第一是挂载选项，客户端挂载时如果带了nosuid，整个挂载点上的 SUID 位一律失效，这是默认的推荐配置，因为共享存储的内容由服务端控制，客户端无法保证其可信。第二是服务端的身份映射策略，很多服务端默认开启root_squash，把来自客户端的 root 身份压成匿名用户，这样一来，即使在服务端把文件属主设成 root、权限设成 4755，客户端拿到的有效身份也不会是 0。

这两个机制都是设计上故意的，不是故障。真要在这类存储上分发可执行程序，正确思路是不要依赖 SUID，改用文件能力或者走本地安装。反过来，如果你在共享存储上看到文件属主变成了nobody或者一个巨大的数字，八成就是身份映射在起作用，去服务端看导出配置里的映射规则，比在客户端反复chown有用得多。

顺带一个实践建议：/home单独分区挂载时加nosuid,noexec是个好习惯，用户家目录里本来就不该有合法的 SUID 程序，关掉这条通道之后，即使某个用户被诱导下载执行了恶意文件，也没法靠 SUID 提升身份。

7. SUID 与文件能力：一次长期的取舍

写到这里必须直面一个问题：既然 SUID 这么危险，有没有粒度更细的替代方案。有，就是文件能力（file capabilities）。它把 root 的一整套特权拆成几十个互相独立的能力单元，比如CAP_NET_BIND_SERVICE只管绑定 1024 以下端口，CAP_NET_RAW只管发原始数据包，CAP_DAC_READ_SEARCH只管绕过文件读权限检查。给可执行文件挂上某一个能力，程序运行时就只有那一项特权，而不是完整的 root 权限。

用法很直接，以"让普通程序绑定 80 端口"为例，传统做法是给程序加 SUID 让属主变 root，能力做法是：

sudo setcap cap_net_bind_service=+ep /usr/local/bin/myserver getcap /usr/local/bin/myserver

getcap输出cap_net_bind_service=ep就说明生效了。e是 effective，表示执行时这个能力在有效集里；p是 permitted，表示进程可以把它提进有效集。两者一般成对出现，只写p的话程序需要自己调用cap_set_proc()才能用上。

两种方案怎么选，我按这张表判断：

实际项目里我的策略是：新程序一律优先用文件能力，只有确实需要完整身份切换（比如要以另一个用户的身份读写它家目录里的文件）时才用 SUID。历史上遗留的 SUID 程序不急着改，但每次做安全审计的时候顺手评估一遍，能换的换掉，换不掉的在文档里标明风险和维护责任人。

文件能力也有它自己的坑。最典型的是扩展属性会被cp、tar、rsync默认丢掉，导致程序在构建机上好好的，部署到目标机就没了特权。打包脚本里要显式保留扩展属性，rsync -X、tar --xattrs，cp则用cp -a。这个坑我在两个项目里踩过，表现都是"本地测试通过、线上报权限不足"，查半天才想起来是复制文件的时候属性丢了。

最后分享一个我自己长期在用的检查习惯：每次交付涉及权限的程序之前，先跑一遍下面这三条，输出结果贴进交付文档里。

# 1. 当前系统上所有 SUID 文件，跟上次基线比对 find / -xdev -perm -4000 -type f -print 2>/dev/null | sort # 2. 当前系统上所有挂了能力的文件 getcap -r / 2>/dev/null | sort # 3. 目标程序的实际权限位和扩展属性 stat -c '%A %U:%G %n' /usr/local/bin/myserver getfattr -d -m - /usr/local/bin/myserver 2>/dev/null

三条命令加起来不到十秒，能挡掉绝大多数"部署后权限不对"的低级问题。比事后在日志里翻半天、猜是不是内核策略变了，效率高太多了。