在CentOS系统的权限体系里，粘滞位（sticky bit）是一个既古老又实用的特殊权限。它解决的核心问题是：当一个目录对所有用户开放写权限时，如何防止用户之间互相删除对方的文件。系统安装完成后，执行ls -ld /tmp，你会看到权限部分是drwxrwxrwt，末尾那个t就是粘滞位的标志。很多刚接触Linux的朋友对这个t的含义一知半解，遇到共享目录里文件莫名丢失或者权限混乱时也不知道从粘滞位的角度去排查，这篇文章就把它的原理、设置方法和典型应用场景讲透。
粘滞位的工作原理到底是什么
先从最基础的说起。Linux的权限由三组权限位构成：属主、属组和其他用户，每组包含读（r）、写（w）、执行（x）三种权限。粘滞位属于特殊权限位，只作用于目录，对文件设置粘滞位在现代Linux系统上基本没有意义。
当一个目录被设置了粘滞位之后，规则变得很简单：在这个目录下，只有文件的属主、目录的属主或者root用户才能删除或重命名该文件。注意这里的对比点——如果没有粘滞位，只要用户对目录拥有写和执行权限，就可以删除目录下的任何文件，哪怕这个文件属于别人。这是因为删除文件操作本质上修改的是目录项，判断的是目录的写权限，而不是文件本身的权限。粘滞位就是在目录写权限之上加了一道属主校验，把删除权收回到文件属主手里。
理解这一点非常重要。以/tmp为例，它的权限是777，意味着任何用户都可以在里面创建文件。如果没有粘滞位，用户A完全可以执行rm -f /tmp/用户B的文件，用户的临时文件安全就无从谈起。加了粘滞位后，用户A再尝试删除用户B的文件时，系统会报错Operation not permitted，这就是粘滞位在起作用。
如何查看和设置粘滞位
查看粘滞位最直接的方式是ls -ld命令。粘滞位体现在其他用户权限位的x位置上：如果该位置原本有执行权限，显示为小写t；如果没有执行权限，则显示为大写T。例如drwxrwxrwt表示其他用户有执行权限且带粘滞位，而drwxrwxrwT则表示其他用户没有执行权限但设置了粘滞位，后者通常意味着权限配置有隐患，值得留意。
设置粘滞位有两种常见写法，一种是用数字方式，在三位权限数字前面再加一位，粘滞位的值是1：
# 给目录设置777权限并附加粘滞位 chmod 1777 /home/share # 也可以在已有权限基础上单独添加粘滞位 chmod +t /home/share # 取消粘滞位 chmod -t /home/share # 查看结果 ls -ld /home/share # 输出类似：drwxrwxrwt. 2 root root 4096 share
两种方式的区别在于：数字方式1777会一次性重设全部权限，适合新建目录时一步到位；符号方式+t则只增删粘滞位，不动其他权限，适合对已有目录做增量调整，生产环境下更推荐后者，避免误覆盖原有权限。另外要注意，chown、chmod递归操作不会影响粘滞位本身，但如果用数字方式重设权限时忘了写第一位，粘滞位会被悄悄清掉，这是运维中很常见的坑。
粘滞位的典型应用场景
场景一：多人共享的临时目录
团队服务器上经常需要一块公共区域供所有用户存放临时文件，比如编译中间产物、导出的数据文件。这种目录通常设为777，但不加粘滞位的话，任何一个用户误执行一次rm -rf *就会波及所有人的文件。加上粘滞位后，每个用户只能清理自己的文件，误删的影响范围被限制在个人目录内，这是粘滞位最经典的用法。
场景二：FTP或Samba上传目录
对外提供上传服务的目录也有类似需求。多个客户端往同一目录写文件，你不希望客户端A能删掉客户端B刚上传的文件。把上传目录设置为1777（配合服务端的chroot等安全策略），就能保证各客户端之间文件互相隔离。需要注意的是，如果服务进程本身以root身份运行，粘滞位对它无效，root始终可以删除任何文件，所以还要结合服务自身的用户映射机制来设计。
场景三：Web应用的文件交换区
有些Web应用需要多个系统账号协作，比如nginx用户负责读取、php-fpm用户负责写入、开发账号负责部署。当大家共用一个交换目录时，粘滞位配合合理的属组设置，可以让每个账号只对自己的产物有删除权。这种场景下常见做法是：目录属组设为公共组并加SGID保证新建文件继承属组，再加粘滞位限制删除行为，两者配合使用效果最好。
粘滞位与SUID、SGID的区别与配合
Linux共有三种特殊权限，很多人容易混淆。SUID作用于可执行文件，执行者临时获得文件属主的身份，典型例子是/usr/bin/passwd；SGID作用于目录时，新建文件会继承目录的属组，常用于团队协作目录；粘滞位作用于目录，限制删除权限。三者数字表示分别是4、2、1，可以组合使用，比如2777表示SGID加满权限，3777表示SGID加粘滞位。
在实际配置团队共享目录时，一个常见的完整方案是：chmod 3777 /home/teamshare。这样所有用户都能读写，新文件自动归属团队组方便组内互访，同时粘滞位防止跨用户删除。当然是否需要组内互删要根据业务判断，如果团队内部高度互信，只要1777甚至2777就够了，不必机械套用。
常见问题与排查思路
排查粘滞位相关问题时，第一步永远是ls -ld看目录权限。如果用户报告无法删除自己明明有写权限的目录下的文件，先检查该目录是否带t标志。其次检查文件系统挂载选项，个别网络文件系统对粘滞位支持不完整，行为可能与本地文件系统不同。最后，SELinux也可能拦截删除操作，可以临时用setenforce 0对比测试（排查完记得恢复），并结合/var/log/audit/audit.log定位具体原因。
还有一个细节值得注意：用cp -a或rsync -a复制目录时会保留粘滞位，但某些打包工具解压时可能不会还原特殊权限位，迁移目录后要重新检查一遍。养成配置完成后用ls -ld复核的习惯，能避免绝大多数由权限位丢失引发的线上问题。
总结一下，粘滞位是一个小而精的权限控制工具，成本几乎为零，却能解决共享目录下的互删问题。在CentOS上凡是需要多人写入同一目录的场景，都值得先想一下是否该加上这个t。配合SGID和合理的属组规划，可以把共享目录的权限模型搭得既开放又安全。
粘滞位sticky bitCentOS权限管理修改时间：2026-09-03 10:35:23