Exim4调用PHP脚本写入/var/log/myapp文件夹的权限问题求助

嘿，你已经把权限配置的大框架搭起来了，但有几个容易忽略的小细节可能导致nobody用户还是没法正常写入/创建文件，我帮你梳理下可能的问题点：

• 先确认nobody真的加入了目标组
  运行id nobody命令看看输出里有没有eximapplog这个组。因为usermod添加组后，用户需要重新登录才会生效，但nobody是系统服务用户，不会主动登出再登录。这时候你可以重启Exim4服务（sudo systemctl restart exim4），让它重新加载用户的组信息，之后再测试。

• 给文件夹设置SGID位
  默认情况下，新创建的文件会继承创建者的主组，而不是所在文件夹的组。这就导致如果nobody创建文件，文件的组可能还是nobody的主组，而不是eximapplog，后续bob可能没法编辑；反过来bob创建的文件组是bob的主组，nobody也没法改。
  解决方法是给文件夹加上SGID位：

  sudo chmod g+s /var/log/myapp
  

  这样不管是谁在这个文件夹里创建文件/子文件夹，都会自动继承eximapplog组权限，双方都能正常读写。

• 检查SELinux或AppArmor的限制
  很多Linux发行版默认启用了SELinux（比如CentOS、RHEL）或者AppArmor（比如Ubuntu），这些安全模块会在文件系统权限之外再做一层限制。哪怕你把文件夹设成777，只要安全模块不让Exim4访问，它还是写不了。
  可以临时关闭SELinux测试：sudo setenforce 0，然后测试Exim4能不能写入。如果成功了，那需要给这个目录添加SELinux规则：

  sudo semanage fcontext -a -t var_log_t "/var/log/myapp(/.*)?"
  sudo restorecon -R /var/log/myapp
  

  如果是Ubuntu的AppArmor，你需要编辑Exim4的配置文件（通常在/etc/apparmor.d/usr.sbin.exim4），添加一行/var/log/myapp/** rw,，然后重启AppArmor服务。

• 检查PHP脚本的umask设置
  你的PHP脚本可能设置了umask，导致创建的文件权限比预期的严格。比如如果umask是022，那新文件的权限会是644，组用户只有读权限。可以在脚本的开头加上：

  umask(002); // 让新文件/文件夹的组权限保持读写
  

  这样创建的文件权限会是664，文件夹是775，刚好符合你的需求。

• 确认父目录的权限
  最后别忘了检查/var/log目录的权限，运行ls -ld /var/log看看，输出应该是类似drwxr-xr-x的格式——其他用户需要有执行权限（x位），才能进入这个目录访问里面的子文件夹。如果/var/log的权限是drwxr--r--，那nobody连进入目录的权限都没有，更别说写入了。

你可以按照这个顺序一步步排查，应该能解决问题。

备注：内容来源于stack exchange，提问作者Tom