selinux相关的permission-denied问题

起因

最近将系统更新到了centos7,由于centos7 采用systemctl 替代了原有server相关的服务管理接口。当使用

systemctl start nginx.service

时,系统提示出现错误,请运行:

systemctl status nginx.service -l

-l 表示显示完整的提示日志,否则会出现提示日志缩略的问题。运行status指令时,出现下面日志:

[root@server]# systemctl status nginx.service -l
nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled)
   Active: failed (Result: exit-code) since Fri 2016-01-08 11:56:09 EST; 30min ago
  Process: 704 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=1/FAILURE)
  Process: 698 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)

Jan 08 11:56:09 chicago1 nginx[704]: nginx: [emerg] BIO_new_file("/xxx/xxx.crt") failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/xxx/xxx.crt','r') error:2006D002:BIO routines:BIO_new_file:system lib)
Jan 08 11:56:09 chicago1 nginx[704]: nginx: configuration file /etc/nginx/nginx.conf test failed
Jan 08 11:56:09 chicago1 systemd[1]: nginx.service: control process exited, code=exited status=1
Jan 08 11:56:09 chicago1 systemd[1]: Failed to start The nginx HTTP and reverse proxy server.
Jan 08 11:56:09 chicago1 systemd[1]: Unit nginx.service entered failed state.

分析

因为看到'Permission denied',所以先检查文件权限,ll指令查看,文件的权限是没有问题。想起的了之前遇到的部署nginx时,部署在自定义目录下不行,部署在nginx默认安装目录'/usr/share/nginx/html' 下就可以的问题。当时也是直接ls查看文件属性,两边的文件权限和归属都是相同的。

今天再次遇到这个问题是,觉得两次应该是同一个问题,所以有必要彻搞清楚,因为是权限问题,所以还是要从权限策略方面入手,于是想到selinux,在之前的系统中默认都是关闭的,但在新系统中我们并没有关闭。于是确认下:

[root@server]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

于是我们查看下selinux策略配置:

ls -lrtZ /usr/share/nginx/html

显示如下:

-rw-r--r--. root root system_u:object_r:usr_t:s0

而我们自己的目录:

-rw-r--r--. root root unconfined_u:object_r:default_t:s0

解决

于是修改策略:

chcon -R -u system_u /xxx/
chcon -R -t usr_t /xxx/

重新执行,发现还是失败,最终确认,需要重启后,才能生效。