弱电知识

fuid/cuid/uid

时间：2026-05-13 08:24:42 作者：网际迅联来源：阅读：172

内容摘要：在 Linux 和 Unix-like 系统中，UID、CUID、FUID是与进程身份和权限控制密切相关的三个关键标识符（Identifiers），它们共同支撑着系统级的访问控制、特权分离与能力继承机制。尤其在现代容器、命名空间（namespaces）和能力（capabiliti......

在 Linux 和 Unix-like 系统中，UID、CUID、FUID 是与进程身份和权限控制密切相关的三个关键标识符（Identifiers），它们共同支撑着系统级的访问控制、特权分离与能力继承机制。尤其在现代容器、命名空间（namespaces）和能力（capabilities）模型下，三者分工明确、不可混淆。

以下内容严格依据 Linux 内核文档（v6.12+）、POSIX 标准、man 7 credentials 及 man 2 setresuid 等权威资料，结合 <extra-info>今天是2026-05-11</extra-info> 的内核现状（如 user_namespaces 全面启用、CAP_SETUIDS 细粒度管控），为你清晰、准确、无歧义地解析：

✅ 一、核心定义：谁是谁？（一句话定位）

缩写	全称	中文含义	本质角色	是否可被普通进程修改？
`UID`	User Identifier	实际用户 ID（Real UID）	进程启动时继承自父进程或登录用户的原始身份，用于审计日志、资源所有权（如文件属主）、信号发送权限判定	❌ 否（仅 `setuid()`/`setresuid()` 在满足特权条件下可设；普通进程只能设为自身 `UID` 或 `SUID`）
`EUID`	Effective User Identifier	有效用户 ID	决定当前进程对系统资源的访问权限（如能否读 `/etc/shadow`、能否 `kill` 其他进程）。是“此刻正在以谁的身份行事”的 ID	✅ 是（若拥有 `CAP_SETUIDS` 或 `EUID == 0`，或 `SUID` 位程序可临时提升）
`SUID`	Saved Set-User-Identifier	保存的设置用户 ID	当进程执行 `setuid()` 时，原 `EUID` 被暂存于此，供后续权限“降权-升权”循环使用（如 `sudo`、`passwd`）	✅ 是（通过 `setresuid()` 显式设置）
`FSUID`	File System User Identifier	文件系统用户 ID	专用于文件访问权限检查（`open()`, `stat()`, `chmod()` 等），可独立于 `EUID` 设置，实现“权限隔离但不切换身份”（如 NFS 服务器、安全沙箱）	✅ 是（需 `CAP_SETUIDS`）
`CUID`	Creator User Identifier	创建者用户 ID	仅存在于内核对象中（如 IPC 对象：消息队列、信号量、共享内存），记录该对象创建时的 `EUID`，用于后续 `IPC_OWNER` 权限判定	❌ 否（内核只读，用户态不可改）

⚠️ 关键澄清：

FUID 不是标准术语！你提到的 FUID 很可能是指 FSUID（File System UID）——这是 Linux 特有的、被广泛使用的正式名称；

CUID 也常被误称为 Creator UID，但它不是进程的属性，而是IPC 对象（struct kern_ipc_perm）的字段，存在于内核数据结构中；

没有独立的 FUID 进程状态字段；fsuid 是进程的一个可设字段（task_struct->cred->fsuid），而 cuid 是 IPC 对象的只读元数据。

✅ 正确术语表（2026 Linux v6.12+）：

名称	内核字段 / man 手册	用途
`uid`	`ruid`（real uid）	`getuid()` 返回值；初始 UID
`euid`	`euid`（effective uid）	`geteuid()`；权限判断主力
`suid`	`suid`（saved uid）	`setresuid(-1, euid, -1)` 可恢复 `euid`
`fsuid`	`fsuid`	`setfsuid()` 设置；仅影响 `vfs_permission()`
`cuid`	`ipc_perm.cuid`（in `struct msqid_ds`, `struct semid_ds` etc.）	IPC 对象创建者身份，只读

✅ 二、工作原理图解：一次 `passwd` 命令中的 UID 流动（经典案例）

$ ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root ... /usr/bin/passwd   ← SUID 位已置位（s）

当普通用户 alice（UID=1001）执行 passwd 时：

阶段	`UID`	`EUID`	`SUID`	`FSUID`	关键动作	权限效果
启动前	1001	1001	1001	1001	`alice` 执行 `/usr/bin/passwd`	`EUID` 由 `SUID` 位自动提升 → `EUID=0`
启动瞬间	1001	0	0	1001	内核检测到 `SUID` 位，将 `EUID` 设为文件所有者（root）UID	获得读写 `/etc/shadow` 权限
验证旧密码后	1001	0	0	1001	`passwd` 调用 `setresuid(1001, 1001, 0)`	`EUID=1001`（降权），但 `SUID=0` 保留（可再提权）
写入新密码前	1001	1001	0	1001	`passwd` 调用 `setresuid(0, 0, 0)`	`EUID=0`（再提权），安全写入 `/etc/shadow`
退出前	1001	1001	0	1001	`setresuid(1001, 1001, 1001)`	彻底清除特权，`SUID` 也重置

? FSUID 在此流程中保持 1001，确保即使 EUID=0，对 alice 自己家目录的访问仍按 1001 判定（避免提权后意外覆盖用户文件）。

✅ 三、`FSUID` 的独特价值：为什么需要它？（2026 安全实践）

FSUID 的存在，解决了 EUID 单一模型无法应对的细粒度权限隔离需求：

场景	问题	`FSUID` 解法
NFS 服务器（nfsd）	`nfsd` 进程需以 `root`（`EUID=0`）运行以绑定 2049 端口，但处理客户端请求时，必须以客户端 UID 检查文件权限，否则所有客户端都获得 root 权限！	`nfsd` 在处理每个请求前： `setfsuid(client_uid)` → 文件操作按 `client_uid` 判定 `setfsuid(0)` → 恢复自身权限做管理操作
容器运行时（runc / crun）	容器进程在 user namespace 中 UID 映射后（如 host UID 1001 → container UID 0），`EUID=0` 在容器内是 root，但在宿主机应受限。文件操作需按映射后的 UID 判定，而非 `EUID`。	`runc` 启动容器时： `setfsuid(mapped_uid)`（如 1001）→ 宿主机文件访问按真实 UID 限权 `EUID` 仍可为 0 以执行 `pivot_root` 等特权操作
安全沙箱（firejail）	沙箱内进程需 `EUID=0` 加载 seccomp 规则、挂载 tmpfs，但打开用户下载的 PDF 时，绝不能以 root 权限读取其家目录！	`firejail` 在执行应用前： `setfsuid(real_user_uid)` → `open("~/report.pdf")` 按用户权限检查 `EUID=0` 保持，用于 `mount --bind` 等沙箱构建

? FSUID 是 Linux 实现 “Privilege Separation”（特权分离） 的基石之一，它让一个进程能同时持有两种身份：

EUID：用于系统调用权限（kill, ptrace, settimeofday）

FSUID：仅用于文件系统访问控制（open, read, write, chown, chmod）
二者解耦，极大提升了安全性与灵活性。

✅ 四、`CUID`：IPC 对象的“出生证明”

CUID 不属于进程，而是内核维护的 IPC 对象元数据，作用极其明确：

IPC 类型	相关结构体字段	何时设置？	何时使用？
消息队列	`msqid_ds.msg_perm.cuid`	`msgget()` 创建时，设为调用者 `EUID`	`msgctl(..., IPC_SET, ...)` 要求调用者 `EUID == cuid
信号量集	`semid_ds.sem_perm.cuid`	`semget()` 创建时，设为调用者 `EUID`	`semctl(..., IPC_SET, ...)` 同上
共享内存	`shmid_ds.shm_perm.cuid`	`shmget()` 创建时，设为调用者 `EUID`	`shmctl(..., IPC_SET, ...)` 同上

? 查看 CUID 的方法（需 root 或 owner 权限）：

# 创建一个消息队列
$ ipcmk -Q
Message queue id: 123456
# 查看详情（含 cuid）
$ ipcs -q -i 123456
...
uid: 1001  gid: 1001  cuid: 1001  cgid: 1001   ← cuid = 创建者 EUID

? CUID 的设计哲学：IPC 对象的所有权归属必须 immutable。即使创建者后来 setuid() 成了 root，也不能随意修改自己创建的队列权限——因为 cuid 锁定了初始创建者身份，保证了 IPC 的可审计性与公平性。

✅ 五、开发者/运维须知：关键命令与检查项（2026 实用清单）

目标	命令 / 方法	说明
查看当前进程所有 UID	`cat /proc/self/status \| grep -E '^(Uid:	Gid:
查看某进程 UID（如 PID 1234）	`cat /proc/1234/status \| grep Uid`	同上，四元组
查看 IPC 对象 CUID	`ipcs -q -i <qid>` / `ipcs -s -i <sid>` / `ipcs -m -i <mid>`	输出中 `cuid:` 字段即创建者 UID
以不同 UID 启动进程（调试用）	`sudo -u username command`（改变 `ruid/euid`） `sudo setpriv --revoke-all --inh-caps=-all command`（更细粒度）	避免直接 `setuid()`，用高阶工具
检查是否启用了 FSUID 支持	`grep CONFIG_FSUID /boot/config-$(uname -r)`	应为 `CONFIG_FSUID=y`（Linux 2.2+ 默认启用）
安全红线（审计重点）	• `find /usr/bin -perm -4000`（检查所有 SUID 程序） • `auditctl -a always,exit -F arch=b64 -S setuid,setresuid,setfsuid`（审计 UID 修改）	`FSUID` 滥用是提权攻击常见入口

✅ 总结：一张表看清全部关系（2026 Linux 准则）

字段	进程属性？	IPC 属性？	可修改？	主要用途	典型场景
`UID` (ruid)	✅ 是	❌ 否	⚠️ 有限（需特权）	审计、信号发送者判定、资源所有者	`ps aux` 显示的 `USER` 列
`EUID`	✅ 是	❌ 否	✅ 是（需 CAP）	核心权限判定（除文件外所有 syscall）	`sudo`, `passwd`, `ping`（cap_net_raw）
`SUID`	✅ 是	❌ 否	✅ 是（需 CAP）	保存 `EUID`，支持“降权-升权”循环	`sudo` 切换用户、`su` 命令
`FSUID`	✅ 是	❌ 否	✅ 是（需 CAP）	仅文件系统访问权限判定	NFS 服务、容器运行时、沙箱
`CUID`	❌ 否	✅ 是（IPC 对象字段）	❌ 否（内核只读）	IPC 对象创建者身份，用于 `IPC_OWNER` 权限	`msgctl(..., IPC_SET, ...)` 权限检查