Sticky Bit可防止用户删除他人上传的文件，仅文件所有者、目录所有者或root能删除或重命名目录内文件；设置命令为chmod 1777 /path/to/upload_dir，权限位末尾显示t表示生效。

在Linux系统中，为公共上传目录（如/var/www/uploads或/tmp/public）设置Sticky Bit，可有效防止用户删除他人上传的文件——即使该目录权限为777，也能守住“只删自己文件”的底线。

Sticky Bit的作用机制

Sticky Bit（粘滞位）作用于目录时，会强制限制文件删除行为：只有文件所有者、目录所有者或root用户，才能删除或重命名该目录下的文件。普通用户即便对目录有写权限，也无法删除别人创建的文件。

它不干涉文件读写，仅约束unlink和rename系统调用，因此不影响正常上传、覆盖、编辑等操作。

如何正确设置Sticky Bit

使用chmod命令为目录添加Sticky Bit：

• 符号法：chmod +t /path/to/upload_dir
• 八进制法：chmod 1777 /path/to/upload_dir（最常用，1=Sticky Bit，777=全开放读写执行）

设置后，用ls -ld /path/to/upload_dir查看权限，末位应显示t（如drwxrwxrwt），小写t表示其他执行位（x）已启用；若为大写T，说明无执行权限，需补上x（如chmod 1777自动包含）。

配合umask与组权限提升协作安全性

单靠Sticky Bit还不够。建议同步配置：

• 将上传目录属组设为共享组（如www-data或uploaders），并赋予组写权限（chmod g+s启用SGID，确保新文件继承目录属组）
• 要求用户加入该组，并设置合理umask（如002），使新文件默认可被同组用户读写
• 避免直接给目录设777却不加Sticky Bit——这是常见疏漏，等于敞开删除大门

典型误用与排查提示

以下情况会使Sticky Bit失效或形同虚设：

• 目录权限未开启执行位（x）：Sticky Bit依赖执行权限生效，chmod 1777比chmod 1770更稳妥
• 用户通过FTP/SFTP或Web应用间接操作：确认后端进程（如Apache、Nginx、vsftpd）以正确用户/组运行，且未绕过权限检查
• 误删的是子目录而非文件：Sticky Bit保护的是目录内的一级条目，若某用户创建了子目录并设为777，其内部文件仍可能被该子目录所有者以外的人误删——需逐层控制