Sticky位是Linux中专为公共目录设计的“防删锁”，它不改变文件读写权限，只约束删除和重命名行为——哪怕目录对所有人开放写权限（777），设置了Sticky位后，用户也只能删自己创建的文件。
哪些目录必须加Sticky位
以下路径在标准Linux发行版中默认已启用，但部署新环境或自建共享目录时需主动检查：
-
/tmp：系统级临时目录，所有用户可写，必须设为
1777（drwxrwxrwt） -
/var/tmp：跨重启保留的临时数据区，同样推荐
1777 -
团队协作目录（如
/shared、/upload）：多人上传/交换文件的场景 -
Web应用上传目录（如 Nginx 的
/var/www/uploads）：防止PHP脚本被恶意覆盖或清空
三步完成Sticky位实战配置
以新建一个安全共享目录 /shared 为例：
- 创建目录并设基础权限：
sudo mkdir /shared && sudo chmod 777 /shared - 添加Sticky位：
sudo chmod +t /shared（等价于sudo chmod 1777 /shared） - 验证是否生效：
ls -ld /shared→ 输出末位应为t，例如drwxrwxrwt
为什么只靠目录权限不够？关键原理说明
删除文件的操作本质是修改目录本身的inode信息（删掉文件名到inode的映射），与被删文件自身的权限无关。所以：
- 即使
file.txt权限是600（仅属主可读写），只要所在目录对用户有写权限，该用户就能rm file.txt - Sticky位让内核在执行
unlink()或rename()前强制校验：当前用户必须是文件属主、目录属主，或是 root - 普通用户尝试删他人文件时，会收到明确错误：
rm: cannot remove 'xxx': Operation not permitted
常见误区与修复建议
- 看到大写
T（如drwxrwxr-T）说明Sticky位已设，但others无执行权限（x）→ 多数共享目录需要x，应补上：chmod o+x /shared - NFS挂载点或容器卷中Sticky位通常失效，这类场景需改用UID/GID隔离或应用层权限控制
- 定期检查敏感目录是否意外丢失Sticky位：
find / -type d \( -perm -1000 \) -ls 2>/dev/null | grep -E '/(tmp|shared|upload)'
