root squash 做了什么
NFS 请求里带的是客户端声称的 UID。服务端 nfsd 在判定权限前，会把 UID 0（以及某些实现里的其他特权身份）替换成匿名身份，默认是 nobody 的 65534，这就是 root squash。它的作用很直接：即使客户端上的 root 被攻破，攻击者也只能以 nobody 的身份操作共享目录，拿不到服务端文件的属主与权限位。相反，no_root_squash 会把这份能力原样交出去。
基本信息
| 适用平台 | Linux/Unix NFS 服务端（nfsd） |
|---|---|
| 默认行为 | root_squash 开启，匿名身份 65534 |
| 相关选项 | root_squash、no_root_squash、all_squash、anonuid/anongid |
| 生效方式 | 改 /etc/exports 后 exportfs -ra |
| 影响面 | 所有以 UID 0 发起访问的写入与属主变更 |
开启后的实际表现
| 操作场景 | root_squash 生效时 | 需要注意 |
|---|---|---|
| root 身份写文件 | 新建文件属主为 nobody | 后续按业务账号管理权限会失效 |
| root 身份 chown | 被拒绝 | 备份恢复保留属主的场景会失败 |
| 普通用户写自己的目录 | 不受影响 | 仍按各自身份判定 |
| root 读取受保护目录 | 可能无权限 | 服务端是否向 others 放行决定结果 |
| 配合 all_squash | 所有人统一压成匿名 | 适合公共只读仓库 |
配置与核对
配置与核对
# 读写共享，保留默认的 root 降级，并让匿名写入落在固定身份上
/data/app 10.0.0.0/24(rw,sync,root_squash,anonuid=65534,anongid=65534)
# 只读分发：即使对端是 root 也改不动内容
/data/pub 10.0.0.0/24(ro,sync,root_squash)
# 核对生效选项
exportfs -v验证降级是否生效
验证降级是否生效
sudo touch /mnt/app/probe.txt && ls -ln /mnt/app/probe.txt # 属主若为 65534 说明已降级
rm -f /mnt/app/probe.txt # 测完清理，避免留下杂物
getent passwd 65534 # 确认服务端匿名账号
ls -ld /srv/data # 检查目录是否对匿名身份开放rw 加 no_root_squash 再配上宽网段，等于把服务端 root 权限交给任何能连上 2049 的主机：对方可以直接改写属主、植入 setuid 程序。确需保留属主的场景（备份、迁移）应改为把来源收窄到单机，或用 Kerberos 做认证后再放宽。
开启 root 降级后最常见的业务投诉是「以 root 跑的服务写不进共享盘」。这不是故障而是预期行为：要么把服务改为以业务账号运行，要么在服务端把目录属主或 ACL 调整到该匿名身份可写，而不是直接关掉 root_squash。
和其他控制手段的关系
root squash 解决的是「身份太强」，不解决「谁能连上来」。它必须和来源限制（导出只允许管理网段）、网络层限制（只在内网放行 2049）一起用。若共享要跨不受信网络，单靠 squash 不够，应改用 sec=krb5 系列，让服务端能验证客户端主机身份，而不是无条件相信 IP 和 UID。