粘滞位是Linux中防止普通用户删除他人文件的唯一内核级机制，它强制要求在设定了粘滞位的目录中，只有文件所有者、目录所有者或root才能删除或重命名文件，且必须同时具备目录的写权限和执行权限，末位显示小写t才表示生效。

为什么普通用户能删别人文件？

因为 Linux 删除文件不看文件权限，而看**父目录的写权限**。只要用户对目录有 w 权限，就能用 rm 删除该目录下任意文件——哪怕那个文件是 root 创建、权限为 000 的。

粘滞位（Sticky Bit）是唯一正确解法

它强制要求：在带粘滞位的目录中，用户只能删除自己拥有的文件。这是内核级行为，不依赖进程协作或权限模拟，rm、mv、unlink() 全部受控。

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

• 设置命令：chmod +t /shared 或 chmod 1777 /shared
• 验证是否生效：ls -ld /shared 输出末位应为 t（如 drwxrwxrwt），不是 T（说明缺少执行权限）
• 必须同时满足两个条件：目录有 w 权限（否则用户根本进不去/列不出），且有 x 权限（否则 t 不生效，显示为大写 T）

常见误配和失效场景

粘滞位不是“设了就完事”，以下情况会直接让它失效：

• /tmp 正常，但你自己建的 /shared 设了 chmod 777 /shared 却没加 t → 用户照样删别人文件
• 设了 chmod 1666 /shared → 目录无 x 权限，ls 都看不到内容，t 显示为大写 T，且不生效
• 目录属主不是 root，而是某个普通用户（如 user1），且未将所有协作者加入同一组 → 粘滞位仍工作，但组权限需额外协调
• 用 chattr +i /shared 锁目录 → 连创建者自己都不能删任何文件，彻底锁死，这不是共享场景要的效果

别和 chattr +i 混用

chattr +i 是让整个目录不可变更（禁止新建、删除、重命名），适用于 /etc 这类静态配置区；而粘滞位是专为共享目录设计的精细控制机制。两者目标不同、生效层级不同、适用场景也完全不重叠。在 /shared 上误加 +i，会导致所有协作者写入失败，服务或脚本直接报 Operation not permitted。