nmp的权限问题分析和selinux

nginx,php-fpm,mysql安装好之后是第一步。
将项目部署上去之后,然后访问,发现仍然无法访问。
按照以下步骤进行错误的排查:

  • 分析nginx的运行日志access.log和error.log
  • 分析php-fpm的运行日志www-error.log
  • 分析代码文件的权限
  • 分析selinux

通过分析,发现静态文件是可以访问了,至少api无法访问。由于前后端的代码分类,nginx在访问静态文件是不会讲请求转发给php进行处理,而是直接返回静态文件。因此可能是访问将请求转发给php-fpm处理时出现错误。

查看nginx的access.log 发现如下错误:
error
在网上搜到的答案基本上就是将nginx.conf中的php的配置改为

1
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

这种解决方式没有错,我之前也是这么解决的。我这里配置是对的,因此确认不是nginx.conf的配置问题。

继续分析php-fpm的运行日志www-error.log
error
在这里找到了原因,文件缺乏写入的权限,因此报错,终止运行。

为了方便,我直接将无法写入的文件夹的权限设置为777。再次访问,发现仍然无法访问,依然是报上面的错误。

那么继续查找问题,开始分析selinux.

查看一下selinux的状态

1
2
3
getenforce
返回
Enforcing

说明selinux是开启并且强制的。为了测试是否是selinux的问题。我暂时关闭selinux

1
2
setenforce 0
将selinux置为Permissive,宽容模式,不会限制访问,仅会给出警告

此时访问网站,发现可以访问网站的api。实在无法解决权限的问题,关闭selinux是个好办法,但是毕竟是会造成一些隐藏的安全问题,后面将会总结一下selinux。

下面分析一下nginx,php-fpm的权限

查看nginx在什么用户下运行:

1
2
ps aux|grep nginx
ps aux|grep php-fpm

nginx进程运行用户组
php-fpm进程运行用户组

再查看一下项目文件的用户和用户组:
501:root

可以看到,三者都是运行在不同的用户和用户组下面,很容易造成权限问题,一次需要统一nginx,php-fpm以及项目文件的用户和用户组。

统一成www

1
2
3
4
5
groupadd www
useradd -g www www
修改nginx.conf 中的user
修改php-fpm.conf中的user和group
修改代码目录权限740

selinux

在前面我们配置web环境以及用户组之间的关系以及将文件权限设置成777之后,仍然会报错,没有访问权限,这时就需要从selinux上找问题。selinux是linux中的一个安全强化模块,它在linux的传统文件权限和用户关系上增加了一层访问控制,实现了更加严格的访问权限控制。

下面分析一下
传统文件权限和账户关系:自主访问 ,DAC

  • 自主访问:依据进程的所有者与文件资源的rwx权限来决定有无访问权限
  • Root具有最高的访问权限
  • 用户可以取得进程来控制文件权限

强制访问控制:MAC

  • 可针对特定的进程与特定的文件资源进行权限控制
  • 控制的主体变成了进程而不是用户
  • 每个文件资源也有针对该主题进程设置可取用的权限。

根据两种访问控制来判断,进程在向日志文件laravel.log写入时,没有通过selinux的审核。下面将分析selinux的日志,找出解决办法

查看selinux报错信息:

cat /var/log/messages | grep setroubleshoot

selinux log

根据提示

1
sealert -l f50903ba-8d28-407d-bfc8-15fbf7785605

selinux log

这里selinux给出了更加详细的信息,并且也给出了建议

1
2
semanage fcontext -a -t httpd_sys_rw_content_t 'xxx'
restoecon -v 'xxx'

设置后,生效有点慢,需要过一会儿才能生效。