粘滞位是保护共享目录的核心机制，它使有写权限的用户只能删除自己创建的文件：必须设在有执行权限的目录上，用chmod +t或1xxx设置，末位显示小写t即生效；配合属组和setgid（如chmod 2775）可实现组内协作安全。
在多用户 Linux 环境中，只要目录对某用户有写权限（w），该用户默认就能删除目录里任何文件——哪怕那文件是别人创建的。这显然不适合共享目录。Sticky Bit（粘滞位）就是为解决这个问题而生的核心机制：它不改变读写执行权限，只额外加一道“删除门槛”。
Sticky Bit 的作用逻辑
当一个目录设置了粘滞位，用户能否删除其中某个文件，不再只看目录有没有 w 权限，还要满足以下任一条件：
- 是该文件的所有者
- 是该目录的所有者
- 拥有 root 权限
换句话说，普通用户仍可自由创建、读取、修改（若文件本身允许）、重命名自己的文件，但无法触碰他人文件——即使他们对目录有完全的 rwx 权限。
如何正确设置并验证
粘滞位必须设在目录上，且该目录对目标用户（通常是 others）必须有执行权限（x），否则不生效（显示为大写 T，而非小写 t）。
-
快速启用：运行
chmod +t /shared，不改动原有权限，只加粘滞位 -
一步设定完整权限：如需所有人可读写执行并启用保护，用
chmod 1777 /shared（首位 1 表示 sticky bit） -
验证是否生效：执行
ls -ld /shared，看到末位是小写 t（例如drwxrwxrwt）即成功 -
常见错误：若显示
drwxrwxrwT，说明缺少 other 的 x 权限，补上即可：chmod o+x /shared
实际协作中的组合配置
单靠粘滞位能防误删，但要支持高效协作，还需配合属组与 setgid：
- 把所有协作用户加入同一组，例如
usermod -aG teamusers alice bob - 将共享目录属组设为该组：
chgrp teamusers /shared - 开启组写 + setgid：
chmod 2775 /shared（2 表示 SGID，保证新文件自动继承 teamusers 组；775 保证组内可写可执行） - 再加粘滞位：
chmod +t /shared或直接用chmod 12775 /shared（注意：四位八进制中 SGID 和 Sticky Bit 可共存，1+2=3，即3775）
最终效果：组内成员可自由新建/编辑文件，新文件自动归属 teamusers 组，且谁都只能删自己建的文件。
典型适用场景
这类配置不是“可选优化”，而是多用户共享环境的安全基线：
-
/tmp 和 /var/tmp：系统默认使用
1777，所有用户可写，但互不干扰 -
开发团队临时工件目录（如
/work或/scratch） - Samba 或 NFS 共享上传区，防止用户覆盖或清空他人上传内容
- CI/CD 构建产物暂存目录，多个流水线任务并发写入时保障隔离
