Linux下文件组权限配置正确 组内用户写入报Permission denied

核心触发原因是Linux内核默认开启的fs.protected_regular安全防护机制，该机制作用于设置了粘滞位（权限标识带t，你的场景中/tmp权限为drwxrwxrwt，属于典型的全局可写+粘滞位目录）的目录：

• 当该参数处于开启状态时，会直接拦截既不是文件属主、也不是目录属主的用户对目录下常规文件的写入操作，哪怕文件的组权限已经开放写入、用户属于对应属组也会被拒绝。这个拦截发生在传统DAC权限、ACL检查之前，所以会出现权限配置看起来完全正确但依然报Permission denied的情况。

你的场景完全命中触发条件：

• 父目录/tmp属主为root，开启了粘滞位
• 目标文件test属主为www-data，执行写入操作的deploy用户既不是文件属主，也不是父目录属主
• 该机制设计初衷是防范/tmp目录下常见的符号链接劫持、恶意篡改其他用户文件的漏洞，在Ubuntu 20.04+、CentOS 8+等较新的发行版中默认开启。

1. 先确认当前内核参数配置：

sysctl fs.protected_regular

如果返回结果为fs.protected_regular = 1或fs.protected_regular = 2，就代表防护处于开启状态：

• 值为1：默认配置，禁止在粘滞位全局可写目录下写入不属于自身的常规文件、禁止跟随无归属的符号链接
• 值为2：在1的规则基础上，额外增加硬链接相关的防护限制

2. 临时关闭该参数做验证（重启后自动失效，不会永久修改配置）：

sudo sysctl fs.protected_regular=0

再次执行之前的写入命令，如果可以正常写入，即可确认根因就是该参数限制。
3. 若关闭参数后依然报错，按以下顺序排查强制访问控制模块的限制：

• 检查SELinux状态：执行sestatus，如果当前处于Enforcing模式，临时执行sudo setenforce 0切换为宽容模式测试，写入恢复正常就是SELinux上下文配置错误，给对应文件/目录配置正确的安全上下文即可，不建议永久关闭SELinux。
• 检查AppArmor状态：执行aa-status，查看是否存在限制deploy用户、tee程序写入目标路径的规则，调整对应AppArmor配置文件即可。

不建议全局关闭fs.protected_regular参数，会降低系统整体安全性，优先选择以下方案：

• 方案1（推荐）：将需要跨用户共享写入的文件移出/tmp这类带粘滞位的全局可写目录，部署到专门的业务目录（比如/var/www/下的专属业务路径），将目录权限设为775、属组配置为www-data，移除粘滞位，既不会触发内核安全限制，也能满足组内用户共享写入的需求。
• 方案2：如果必须在粘滞位目录下做共享写入，可将需要执行写入操作的用户设为目标文件的属主，或针对特定目录调整安全规则，避免全局降低安全等级。

内容的提问来源于stack exchange，提问作者iRaS