Sticky Bit主要用于保护多用户可写目录中文件的归属安全，防止误删或恶意删除他人文件；典型场景如/tmp目录默认权限drwxrwxrwt，仅文件所有者、目录所有者或root可删除文件。
Sticky Bit 主要用于保护多用户可写目录中文件的归属安全，防止用户误删或恶意删除他人创建的文件。它不是“增强权限”，而是加一道操作限制——即使你对目录有写权限，也不能随便动别人放进去的东西。
公共临时目录（如 /tmp）
/tmp 是 Sticky Bit 最典型、最基础的应用场景。系统默认设为 drwxrwxrwt，所有用户都能在里面建文件、读取公开内容，但只能删自己创建的。这避免了普通用户执行 rm -rf /tmp/* 时意外清空他人临时数据或运行中的进程文件。
- 检查方式：
ls -ld /tmp，末位必须是小写 t - 注意：大写 T 表示 Sticky Bit 已设置但缺少其他用户执行权限（o+x），此时不生效
团队共享上传目录（如 /var/www/uploads）
Web 应用常需让用户上传头像、附件等，这类目录通常需要开放写入，但绝不允许用户互相覆盖或删除。单独设 chmod 777 极其危险，必须搭配 Sticky Bit。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 推荐组合：
chmod 2775 /var/www/uploads（SGID 确保新文件继承属组）+chmod +t /var/www/uploads - 最终理想权限：drwxrwsr-t，既支持组内协作，又锁定删除权
- 属组需包含所有合法上传用户，且目录属组不能是
root（否则普通用户无法写入）
CI/CD 构建产物暂存区
持续集成环境里，多个流水线可能向同一输出目录（如 /build/artifacts）写入构建包。若没 Sticky Bit，后触发的 job 可能 rm -rf 掉前一个 job 的成果，导致部署失败或版本错乱。
- 设置要点：目录属主建议为构建服务账户（如
jenkins），属组为builders - 权限命令：
chgrp builders /build/artifacts && chmod 2775 /build/artifacts && chmod +t /build/artifacts - 验证：普通构建用户能创建文件、重命名自己文件，但
rm别人文件会提示 Operation not permitted
容器与 NFS 环境下的注意事项
Sticky Bit 在跨系统挂载场景中容易失效，这点必须提前识别：
-
NFS：客户端挂载后，
ls -ld显示无 t，是因为 NFS 默认不传递 sticky 元数据；需服务端在/etc/exports中显式启用no_root_squash或确保 UID/GID 映射一致 -
Docker 容器：宿主机设了 Sticky Bit，挂载进容器后通常丢失；应在容器启动后、应用写入前，由容器内 root 执行
chmod +t /shared - 云存储或对象存储网关类方案不支持 Sticky Bit，需改用 ACL 或应用层鉴权替代
