[emerg] open() "/app/gl/log/nginx/major.error.log" failed (13: Permission denied)问题解决

问题复现

在AWS购买了ES2服务器之后,由于没有绑定弹性IP,每次在服务器关闭之后,不但IP发生了变化,连原来配置好的Nginx报出了标题中的问题,字面意思看是访问被拒绝。为什么被拒绝就不得而知了。

问题探索

在使用chomod 反复尝试了把文件夹,以及log文件本身分配权限之后,仍没有什么卵用。在网上资料的犄角旮旯里面找到了不同的提示,这个跟SElinux的开启有关系,当时给了一个命令来临时关闭,尝试了一下,命令生效了,nginx正常跑起来了。命令如下:sudo setenforce 0

再问一步

现在知道这个跟SElinux有关系,但只知道linux,没有听过SElinux。没关系,Google一下。

关于SElinux

安全增强式Linux(SELinux,Security-Enhanced Linux)是一个Linux内核安全模块,其提供了访问控制安全策略机制,包括了美国国防部风格的强制访问控制(Mandatory Access Control,MAC)。
SELinux 的结构及配置非常复杂,而且有大量概念性的东西,要学精难度较大。很多 Linux 系统管理员嫌麻烦都把 SELinux 关闭了。如果可以熟练掌握 SELinux 并正确运用,我觉得整个系统基本上可以到达"坚不可摧"的地步了(请永远记住没有绝对的安全
SELinux 主要作用就是最大限度地减小系统中服务进程可访问的资源(最小权限原则)
在没有使用 SELinux 的操作系统中,决定一个资源是否能被访问的因素是:某个资源是否拥有对应用户的权限(读、写、执行)。只要访问这个资源的进程符合以上的条件就可以被访问。而最致命问题是,root 用户不受任何管制,系统上任何资源都可以无限制地访问。这种权限管理机制的主体是用户,也称为自主访问控制(DAC)
在使用了 SELinux 的操作系统中,决定一个资源是否能被访问的因素除了上述因素之外,还需要判断每一类进程是否拥有对某一类资源的访问权限。这样一来,即使进程是以 root 身份运行的,也需要判断这个进程的类型以及允许访问的资源类型才能决定是否允许访问某个资源。进程的活动空间也可以被压缩到最小。即使是以 root 身份运行的服务进程,一般也只能访问到它所需要的资源。即使程序出了漏洞,影响范围也只有在其允许访问的资源范围内。安全性大大增加。这种权限管理机制的主体是进程,也称为强制访问控制(MAC)
在 CentOS 7 系统中,有三套政策,分别是:1. targeted:对大部分网络服务进程进行管制。这是系统默认使用的政策(下文均使用此政策)。2. minimum:以 targeted 为基础,仅对选定的网络服务进程进行管制。一般不用。3. mls:多级安全保护。对所有的进程进行管制。这是最严格的政策,配置难度非常大。一般不用,除非对安全性有极高的要求。Policy 可以在 /etc/selinux/config 中配置。
SELinux 有三种工作模式,分别是:
1. enforcing:强制模式。违反 SELinux 规则的行为将被阻止记录到日志中
2. permissive:宽容模式。违反 SELinux 规则的行为只会记录到日志中。一般为调试用。
3. disabled:关闭 SELinux。
SELinux 工作模式可以在 /etc/selinux/config 中设定。
如果想从 disabled 切换到 enforcing 或者 permissive 的话,需要重启系统。反过来也一样。enforcing 和 permissive 模式可以通过 setenforce 1|0 命令快速切换。

修改配置

从收集信息可以看出,一般服务器的安全级别还暂时用不到SElinux来强制保护。并且配置和结构非常复杂,所以,使用命令set enforce 0 来临时关闭SElinux,或者在/etc/selinux/config 目录下调整工作模式为disabled 来真正永久关闭SElinux,是解决问题之道。按照要求修改下配置为disabled,然后重启服务器就可以了。

猜你喜欢

转载自blog.csdn.net/u013243938/article/details/106099702