sticky位不阻止上传，只限制删除/重命名；上传取决于wx权限，生效需末位为小写t且o+x存在；限制上传应通过chmod o-w、umask、SELinux或Web层控制。

系统敏感目录加 sticky 位，不是为了限制用户上传，而是防止用户误删或恶意删除他人文件。上传行为本身只取决于目录是否对用户有 w（写）和 x（执行，即进入目录）权限；sticky 位不干涉创建、写入或上传，只约束后续的删除与重命名操作。

Sticky 位对上传行为无影响

只要用户对目录有 wx 权限（例如 rwxrwxrwx 或 rwxrwxrwt），就能正常创建文件、写入内容、上传数据。sticky 位仅在用户尝试 unlink（删除）或 rename（重命名）时起作用——此时内核会校验：操作者是否为该文件所有者、目录所有者，或是 root。

• 用户 A 在 /shared（权限 drwxrwxrwt）中可自由 touch a.txt、cp big.log .、curl -F 'file=@data.zip' http://api/upload
• 但当 A 执行 rm /shared/b.txt（b.txt 属于用户 B），系统返回 Operation not permitted
• 同理，mv /shared/c.txt /shared/d.txt 若 c.txt 不属于 A，也会被拒绝

真正限制上传的机制是常规权限 + umask + SELinux/AppArmor

若需禁止用户上传，应从源头控制写入能力：

• 撤掉其他用户（others）的写权限：chmod o-w /sensitive/dir，这样普通用户连 touch 都失败
• 调整 umask（如设为 0027），使用户新建文件默认无 group/other 写权，配合组管理实现精细控制
• 启用强制访问控制（如 SELinux 的 httpd_can_network_connect 或 deny_ptrace 策略），拦截 Web 应用上传逻辑
• Web 服务层限制（如 Nginx 的 client_max_body_size、upload_pass 路径白名单）比文件系统层更直接有效

敏感目录设置 sticky 位的典型场景

适用于“允许多人写、但必须各自负责自己文件”的共享空间：

• /tmp：系统级临时目录，所有用户可建文件，但不能删别人的东西
• /var/www/uploads（配合 web 组权限）：多个 CMS 或脚本共用上传区，避免插件互相覆盖
• CI/CD 构建产物暂存目录（如 /build/output）：不同 pipeline job 写入各自子目录，主目录加 sticky 防误清

注意：NFS 挂载点或容器 volume 中 sticky 位常失效，必须在挂载后、容器内重新设置（如 docker run -v /host:/container alpine chmod 1777 /container）。

如何验证 sticky 是否生效且可用

仅看 ls -ld dir 输出末尾是 t 不够，还需确认 o+x 存在：

• 正确：权限显示 drwxrwxrwt → 小写 t，表示 sticky 已设且 others 可执行（必要条件）
• 错误：显示 drwxrwxrwT → 大写 T，说明 sticky 位存在但 o+x 缺失，功能不生效
• 安全检查命令：stat /path | grep "Access:"，末两位应为 [0-9]t（如 0777t）
• 推荐设置方式：chmod o+t /path（只改 sticky 位），而非 chmod 1777 /path（可能意外关闭 x）