解决nginx 403错误

如果你在使用nginx的时候遇到了403错误，你应该看看本文提供的解决方法。

再一次遇到403问题，是因为最近搭建了一套CentOS 7的环境。之前搭建环境一直在使用CentOS 6.5，并没有遇到什么特别的不适，也遇到403错误但一般都是文件权限配置错误的问题。但是这次不同。

SELinux是Linux内核实现的一套MAC(Mandatory Access Control, 强制访问控制)安全机制。从CentOS 4开始加入到CentOS中。默认配置为Enforcing模式。我遇到的问题，就是SELinux引起的。

基础概念

SELinux的概念很多，这次简单说一下用到的，以后再专门总结。

• domain domain理解为一个进程的SELinux权限描述，说明了某个进程可以怎样操作某种type文件。

• type type是一个文件权限标签，SELinux给每个问题都进行了标记。SELinux的政策会规定何种domain的进程可以操作某种type的文件。

• context context是进程或文件的上下文，对于进程来说就是domain，对于文件来说是type。

问题

默认配置下，假设我创建了如下文件

/www/index.html

并且修改了所有者为nginx.nginx，nginx正确配置。CentOS 6.6以前，可以正常访问；之后的版本就会报403错误。

问题在于SELinux的限制。上面的文件，其type为default_t，可以通过如下命令查看：

ls -Z /www

CentOS 6.6以前，nginx进程的domain为intrc_t，搜索相关权限：

sesearch -A -s initrc_t -t default_t -c file

可以得到如下结果：

Found 4 semantic av rules:
   allow files_unconfined_type file_type : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint open } ;
   allow initrc_t default_t : file { ioctl read getattr lock open } ;
   allow initrc_t file_type : file getattr ;
   allow files_unconfined_type file_type : file execmod ;

其中第二行，说明了domain为initrc_t的进程可以对type为default_t的file类型文件进行ioctl read getattr lock open这5中操作。这就使得服务运行正常。

而在CentOS 6.6中，SELinux对nginx的权限进行了收紧。nginx的domain变成了httpd_t，再次搜索相关权限：

sesearch -A -s httpd_t -t default_t -c file

将得不到任何结果，也就是说，nginx无权限访问以上文件，也就导致了403错误。

解决

既然知道了问题所在，解决方案也就是顺水推舟了。

1. 关闭SELinux。有网友使用这个方法解决，甚至在有些nginx安装教程里面第一步就是把SELinux禁用，但这样做实际上这相当于没有解决，而且关闭了SELinux安全策略还带来了更大的安全隐患。不推荐。
2. 使用audit2allow工具，创建SELinux政策，default_t type的权限赋给httpd_t。但是这样做同样会带来问题，因为会暴露其他type为default_t的文件权限。

sudo cat /var/log/audit/audit.log | grep nginx | grep denied | audit2allow -M mynginx
sudo semodule -i mynginx.pp

3. 将项目目录的type修改为http_sys_content_t。这是最安全的操作。

chcon -t http_sys_content_t [file]

参考

• https://wiki.centos.org/HowTos/SELinux
• https://www.nginx.com/blog/nginx-se-linux-changes-upgrading-rhel-6-6/
• http://stackoverflow.com/questions/23948527/13-permission-denied-while-connecting-to-upstreamnginx