我的Redis
实例存在一个相当持久的问题。SELinux
处于enforcing
模式时,Redis
服务器无法启动:
[root@server ~]# service redis start
Starting redis-server: [ OK ]
但事实上,它并没有启动,如图所示lsof
。它没有返回任何结果:
[root@server ~]# lsof -i :6379
为了进一步确认它没有运行,有一个 redis 日志:
[5539] 21 Nov 03:44:34 # Opening port 6379: bind: Permission denied
现在,我对管理还很陌生SELinux
,所以请耐心等待,因为我可能遗漏了一些东西。这是我能看到的:
[root@server ~]# semanage port -l | grep "redis"
redis_port_t tcp 6379
[root@server ~]# semanage user -l
SELinux User Prefix MCS Level MCS Range SELinux Roles
....
redis user s0 s0 user_r
....
上述redis
用户最初并不存在,但我尝试将其添加为redis-server
在其下运行。但这没有帮助...
值得注意的是,Redis 服务器是内部使用的,因此它只监听127.0.0.1:6379
。
有人有什么想法吗?
目前,我可以将其SELinux
置于宽容模式,但我真的很想将其收紧并“按规矩”执行。
更新:
[root@server ~]# ausearch -ts recent -m avc
----
time->Thu Nov 24 13:48:13 2016
type=SYSCALL msg=audit(1480013293.595:34717): arch=c000003e syscall=49 success=no exit=-13 a0=4 a1=7ffea866c0f0 a2=10 a3=7ffea866be50 items=0 ppid=1 pid=16468 auid=0 uid=495 gid=495 euid=495 suid=495 fsuid=495 egid=495 sgid=495 fsgid=495 tty=(none) ses=5202 comm="redis-server" exe="/usr/sbin/redis-server" subj=unconfined_u:system_r:redis_t:s0 key=(null)
type=AVC msg=audit(1480013293.595:34717): avc: denied { name_bind } for pid=16468 comm="redis-server" src=6379 scontext=unconfined_u:system_r:redis_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
更新(2)
[root@server ~]# rpm -qa | grep -i redis
redis-2.4.10-1.el6.x86_64
php56w-pecl-redis-2.2.7-1.w6.x86_64
解决方案:
根据@Matthew的建议,我开始分析redis_port_t
和http_port_t
:
[root@server ~]# semanage port -l | grep "redis_port_t"
redis_port_t tcp 6379
[root@server ~]# semanage port -l | grep "http_port_t"
http_port_t tcp 6379, 80, 81, 443, 488, 8008, 8009, 8443, 9000
就这样!端口6379
已添加到两个端口策略中!是的,我记得在开始迁移时做过这件事 :((真丢脸)。
因此,运行此命令解决了该问题:
semanage port -d -t http_port_t 6379
semanage permissive -d redis_t // I don't need this anymore
service redis restart
lsof -i :6379
它就在那里:)
redis-ser 4575 redis 4u IPv4 236174 0t0 TCP localhost:6379 (LISTEN)
答案1
我认为你的政策有些奇怪。
如果您检查审计日志,它会显示虽然 SELinux 源上下文正确标记为 ,但redis_t
目标上下文标记为http_port_t
。尽管您的政策规定应该如此,但事实并非如此redis_port_t
。
这意味着内核和策略不匹配。但端口仍为 6379。
您可能需要检查为您的http_port_t
以及进行了哪些配置redis_port_t
。据我了解,端口策略绑定每个端口/协议只能有一个标签,因此我怀疑您的策略存储中的内容并不反映您服务器中当前的内容。
您可能需要尝试semodule -B
重建并重新加载您的策略以尝试修复同步问题。
如果没有运气,请在端口列表中搜索http_port_t
并更新问题。