sticky bit仅对目录有效，设在文件上被忽略；对目录设置需确保others有执行权，否则显示为t且无效；其核心是限制用户只能删除自己拥有的文件，/tmp设为1777即基于此机制。
Sticky Bit 对普通文件无效，只对目录起作用；设在文件上会被忽略（ls 显示为 T 或 t，但无行为影响）。
为什么 chmod +t 对目录没反应？
常见原因是权限位冲突：Sticky Bit 实际占用的是其他用户（others）执行位（x）的位置。如果目录当前 others 没有 x 权限，chmod +t 会静默失败（或显示为大写 T，表示无执行权+粘滞位）。
- 正确做法是先确保 others 可执行：
chmod o+x /path/to/dir，再加粘滞位：chmod +t /path/to/dir - 或者一步到位：
chmod 1755 /path/to/dir（1表示 sticky bit，755是常规权限） - 验证是否生效：
ls -ld /path/to/dir—— 正常应显示末位为t（如drwxr-xr-t），不是T
chmod 1777 /tmp 是怎么防删别人的文件的？
Sticky Bit 的核心规则是：即使用户对目录有写权限，也**只能删除自己拥有（own）的文件或子目录**。内核在 unlink() 系统调用时强制校验 st_uid == current_uid || is_capable(CAP_DAC_OVERRIDE)。
- 这个机制不依赖 ACL 或 SELinux，是 VFS 层硬编码逻辑
-
/tmp设为1777后，所有用户都能创建文件，但 A 用户无法rm /tmp/b_user_file，即使目录权限允许写 - 注意：文件本身权限不影响该限制 —— 即使 B 用户把文件 chmod 777，A 仍不能删（除非是 root 或 cap）
哪些场景不该乱加 Sticky Bit？
Sticky Bit 不提供加密、审计或访问控制能力，滥用反而引发权限困惑和误操作。
- 协作项目目录（如 Git 仓库）：加 sticky bit 会导致开发者无法清理他人临时文件，破坏 workflow
- Web 服务器上传目录（如
/var/www/uploads）：若用 PHP-FPM 运行，实际删除动作由 web 用户（如www-data）发起，sticky bit 会阻止所有非该用户的清理操作，包括运维手动维护 - 挂载了 noexec 或 nosuid 的文件系统：sticky bit 仍可设置，但部分旧内核或容器环境可能忽略它（建议用
ls -ld实测）
真正需要 sticky bit 的地方其实非常有限：仅限多用户共享、且必须允许任意人建文件但禁止随意删他人内容的目录（/tmp、/var/tmp 是典型）。其他情况优先考虑 umask、ACL 或服务级隔离。
