Sticky Bit 无法单独防止文件覆盖，因其仅限制删除和重命名，不控制写入；防覆盖需四步协同：1777目录权限、严格umask、SGID统一属组、上传路径隔离。
匿名上传目录本身不涉及用户身份认证，所以“只能上传、不能相互覆盖”这个目标不能靠 Sticky Bit 单独实现——Sticky Bit 只管删除和重命名，不管写入和覆盖。真正阻止覆盖的关键，在于让每个用户上传的文件归属明确、互不干扰，同时限制对他人文件的写权限。Sticky Bit 在这里起的是兜底防护作用：防止用户删掉别人文件后“腾出位置”再传同名文件来变相覆盖。
核心逻辑：覆盖 ≠ 上传，而是写入已有文件
Linux 中“覆盖一个文件”，本质是打开该文件并以 O_TRUNC 方式写入（或先 unlink 再新建同名文件）。只要用户对目标文件有写权限，就可能覆盖；而 Sticky Bit 并不限制写操作本身。因此，要防覆盖，必须切断“对他人文件的写权”这条路径。
关键配置组合
以下四步缺一不可：
- 目录设为 1777 + 执行位：chmod 1777 /var/www/uploads。确保末位是小写 t（如 drwxrwxrwt），所有用户可进、可建、可删自己文件，但删不了别人的
- 禁用组/其他用户的写权限到具体文件：靠 umask 控制。所有上传进程（如 Nginx 的 PHP-FPM、Python Flask 服务）必须运行在 umask 0002 或更严格（推荐 0007）环境下，使新文件默认权限为 660 或 600（即 group/other 无写权）
- 强制文件属组统一 + SGID：chgrp uploaders /var/www/uploads && chmod 2775 /var/www/uploads。这样所有新创建的文件自动继承属组 uploaders，但因 umask 限制，其他组员仍无法写——除非你主动开放组写，否则覆盖不会发生
-
上传逻辑按会话/用户隔离路径：后端不要把所有文件都丢进根上传目录。应按请求特征生成子目录，例如：
/uploads/20260721/a3f9b2/ → 来自 IP+时间戳哈希
/uploads/user_anon_7728/ → 临时会话 ID
/uploads/md5hash_of_filename/ → 文件指纹防重
这样物理隔离天然杜绝覆盖，Sticky Bit 则保护这些子目录不被误删
为什么不能只靠 Sticky Bit？
假设目录权限是 1777，用户 A 上传了 report.pdf，权限为 644；用户 B 也上传同名文件，如果后端直接 open("report.pdf", O_WRONLY|O_TRUNC)，B 就能覆盖 A 的内容——因为 Sticky Bit 不拦截 open() 系统调用，只拦 unlink()/rename()。只有当 B 先删再传，Sticky Bit 才生效。所以防覆盖必须从文件级权限和路径设计入手。
验证与运维要点
定期检查三项：
- ls -ld /var/www/uploads → 必须显示 drwxrwsrwt（注意 s 是 SGID，t 是 Sticky）
- 上传后执行 ls -l /var/www/uploads/* → 新文件属组应为 uploaders，权限不应含 w 给 group/other（如 -rw-r-----）
- 测试非属主用户是否能 touch /var/www/uploads/existing.txt → 应失败；能否 rm /var/www/uploads/existing.txt（属主为别人）→ 应提示 Operation not permitted
