Linux 临时目录为什么能写却删不掉：sticky bit、umask 与目录权限

用Linux久了，很多人都碰到过临时目录里的反常现象：应用用户能在 /tmp 创建文件，也能正常往里面写入内容，换另一个账号去清理的时候却收到 Operation not permitted。这通常不是文件损坏，而是目录权限、文件属主和 sticky bit 共同决定了“谁可以删除目录项”。

判断临时目录权限时，先看父目录是否允许写入，再看目录有没有 sticky bit，最后区分“创建文件”“改文件内容”和“删除文件”三个动作；不要因为文件本身可写，就推断任何用户都能删除它。

先复现一次：写入成功为什么不代表删除成功

找一台测试 Linux 主机，用两个普通账号做一个小实验。不要直接在生产目录里改权限，先创建带唯一后缀的实验目录：

lab=/tmp/perm-lab-$$
mkdir "$lab"
chmod 1777 "$lab"
printf 'owner=%s\n' "$USER" > "$lab/report.txt"
ls -ld "$lab"
ls -l "$lab/report.txt"
namei -l "$lab/report.txt"

创建者可以继续写入自己的文件；另一个账号通常可以读取它（取决于文件的实际模式），也能在目录中创建自己的文件，但删除 report.txt 时会被 sticky bit 拦住。这里先别急着执行 chmod 777 report.txt，那只会改变文件内容权限，不能把删除权从目录规则里拿出来。

删除动作看父目录：文件权限不是唯一门槛

在 Linux 文件系统里，文件名是父目录中的一个目录项。删除动作本质上是在父目录中移除这个名字，因此排查时要把两个对象分开看：

可以用 stat 和 namei 把权限链拆开：

stat -c 'path=%n mode=%a owner=%U group=%G' "$lab" "$lab/report.txt"
namei -l "$lab/report.txt"
ls -ld /tmp "$lab"
getfacl -p "$lab" 2>/dev/null | sed -n '1,20p'

如果目录显示为 drwxrwxrwt，最后那个 t 就是 sticky bit。它不是“目录不可写”的标志，恰恰相反，/tmp 仍然允许多个用户写入；它限制的是普通用户对他人目录项的删除和改名。

sticky bit 的边界：谁能删除，谁不能删除

对设置了 sticky bit 的目录，目录项的删除或改名通常只允许目录所有者、文件所有者或特权用户完成。这个规则正是公共临时目录需要的隔离：大家可以把自己的临时文件放进去，但不能随手删掉别人的文件。

chmod 1777 /tmp
stat -c '%A %a %U %G %n' /tmp
# drwxrwxrwt 1777 root root /tmp

如果你维护的是单个服务的临时目录，不建议为了省事直接复用全局 /tmp。更清晰的方式是创建一个服务专属目录，把属主、组和模式写进部署步骤：

install -d -o order -g order -m 0750 /var/lib/order/tmp
namei -l /var/lib/order/tmp
sudo -u order sh -c 'printf ready > /var/lib/order/tmp/health.txt'
stat -c '%A %a %U %G %n' /var/lib/order/tmp/health.txt

专属目录让清理任务只面对一个明确的边界。若确实需要同组协作，可以用组写权限和合适的默认创建策略，但要先确认哪些账号应该能读、写、改名和清理，别用一个过宽的模式掩盖职责不清。

umask 只管新对象：它不会修复旧文件权限

umask 是进程创建文件或目录时的权限屏蔽值。它参与计算初始模式，例如程序请求以 0666 创建普通文件，当前 umask 0027 时，通常会得到 0640；请求创建目录时，基础模式通常是 0777，再由 umask 屏蔽对应位。

umask
umask -S
old_umask=$(umask)
umask 027
touch "$lab/umask-file"
mkdir "$lab/umask-dir"
umask "$old_umask"
stat -c '%A %a %n' "$lab/umask-file" "$lab/umask-dir"

这个实验只影响后续创建的对象。已经存在的文件不会因为进程的 umask 改变而自动收紧或放开；要修复旧对象，应明确使用 chmod、chown 或 ACL，并先限定目标路径。

还要注意启动方式。交互式登录终端里看到的 umask，不一定等于服务管理器、容器入口或定时任务使用的值。对服务来说，最好在服务的运行契约或启动代码中显式记录期望权限，并用一个实际生成的文件做验收，不要只看部署脚本的某一行。

临时文件清理交给生命周期规则，不要靠宽泛删除

临时文件的清理应该同时考虑年龄、文件属主、正在使用的进程和目录白名单。直接写一个全局递归清理命令风险很高：它可能误删仍在使用的文件，也可能与应用的写入过程竞争。

使用带 tmpfiles 管理能力的 Linux 发行版，可以把专用目录交给 tmpfiles.d 规则管理。示例只展示规则形态，正式落地前先用测试目录验证：

# /etc/tmpfiles.d/order-worker.conf
d /var/lib/order/tmp 0750 order order 7d

修改规则后，可先查看当前配置来源，再以明确的规则文件为边界进行检查。清理策略应由管理员维护，应用自身仍应在任务结束后尽快删除不再需要的文件：

tmpfiles-tool --cat-config | grep -A2 -B2 'order/tmp'
tmpfiles-tool --clean /etc/tmpfiles.d/order-worker.conf
find /var/lib/order/tmp -maxdepth 1 -type f -printf '%TY-%Tm-%Td %TH:%TM %u %s %p\n' | sort

如果要做一次修复前预览，应使用发行版对应 tmpfiles 工具支持的预览参数，并先阅读本机手册；不要把不确定的参数直接带到生产命令里。清理后用文件数、总字节数和业务健康检查三组信号复核，而不是只看命令返回成功。

遇到删不掉时，按四层顺序定位

1. 确认目标路径：用 readlink -f、findmnt -T 和 namei -l 排除软链接、挂载点或路径层级误判。
2. 确认目录规则：用 stat 看父目录模式、属主、组和 sticky bit，必要时看 ACL。
3. 确认文件状态：用 stat 看文件属主、时间和模式，用 lsof 判断是否仍被进程打开；文件被打开不等于不能删除，但会影响空间回收和业务行为。
4. 确认清理身份：查看定时任务、容器用户和服务管理器实际使用的账号，避免把“权限不足”误判成“文件异常”。

权限修复要尽量窄。比如只让服务用户清理自己的目录，可以把清理动作放到服务用户下；如果必须跨用户清理，就建立明确的组权限或特权清理服务，并记录删除范围。不要为了临时止血把整棵目录改成 0777。

常见问题

文件权限是 777，为什么别人还是删不了？

删除主要受父目录影响。公共目录如果设置了 sticky bit，普通用户不能删除其他用户拥有的目录项，即使目标文件本身是 777。

去掉 /tmp 的 sticky bit 会怎样？

目录仍可能可写，但普通用户之间的文件隔离会变弱，用户可能删除或改名其他用户的临时文件。除非有明确的维护方案，不要改动系统公共临时目录的这个保护位。

umask 027 会让旧文件变成 640 吗？

不会。umask 只影响后续创建对象的初始模式；旧文件需要用明确的权限或属主变更动作处理。

文件正在被进程打开，能不能删除？

在 Linux 中，打开文件仍可能被删除；目录项消失后，进程继续占用的空间要等最后一个文件描述符关闭才回收。是否应该删除，仍要结合应用状态和回滚方案判断。

临时目录的权限问题，关键不是记住一组万能数字，而是把对象、动作和身份拆开：父目录决定目录项能否被创建或删除，文件模式决定内容能否读写，sticky bit 保护公共目录里的所有权边界，umask 决定新对象的起点。按这条链路检查，通常能在改权限之前先找到真正的阻塞点。