场景描述：
当selinux安全策略处于enforce模式下时，无法启动http服务器，可能是因为某个文件/文件夹（例如openssl证书）的安全上下文（Security Context）配置不当，引起应用层服务无法访问。
初步排查：
1.systemctl查询service status，查看错误日志
2.出现情况”xxx”文件不存在，然而使用管理员cat 该文件又可以正确读取，则可能是selinux拒绝了服务的访问
3.临时将selinux设置为宽容模式 setenforce 0(严格模式permissive命令为setenforce 1)
4.再次启动服务，发现服务正常启动，则确定是selinux安全策略引起的问题
5.查询selinux拦截的具体信息，从 /var/log/audit 目录打开安全日志，可以看到示例的如下信息：
type=AVC msg=audit(1731787608.014:430):
avc: denied { getattr } for pid=xxx comm="xxx" path="xxx" dev="dm-0" ino=396436
scontext=system_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=1- type=AVC表明这是一条与访问向量缓存相关的审计日志条目。
- denied表明SELinux拒绝了访问请求。
- { getattr }是请求的操作类型，即获取文件属性。
- pid=xxx comm="xxx"表明请求是由进程ID为xxx的xxx进程发起的。
- path="xxx"是被访问文件的路径。
- dev=“dm-0” ino=396436提供了被访问文件的设备信息和inode号。
- scontext=system_u:system_r:httpd_t:s0是源安全上下文，即httpd进程的安全上下文。
- tcontext=unconfined_u:object_r:admin_home_t:s0是目标安全上下文，即被访问文件的安全上下文。
- tclass=file表明被访问的对象是文件。
- permissive=1表明SELinux当前处于permissive模式，即即使访问被拒绝，也不会阻止操作执行（但会记录日志）。
解决思路：
1.永久使selinux处于permissive宽容模式（不安全）：
修改 /etc/selinux/conf 下的文件，设置SELINUX=permissive
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=permissive
修改完之后重启reboot，使用sestatus查询selinux状态
2.修改被访问文件的安全上下文
文件的安全上下文重要的3个属性：
-u 用户use
-r 角色role
-t 文件类型type
可以通过安全策略配置获得访问权限，但对于自定义的文件/文件夹，直接修改它的安全上下文更好。
通过日志我们可以看到程序的源安全上下文 ：
system_u:system_r:httpd_t:s0
也可以通过ls -Z
system_u:object_r:httpd_config_t:s0
找到不能访问的文件/文件夹，ls -Z 查询安全上下文scontext：
unconfined_u:object_r:admin_home_t:s0
使用 chcon [选项] [安全上下文] 文件或目录 修改安全上下文，例如；
chcon -u system_u xxx.doc
chcon -t httpd_t xxx.doc
就实现了把xxx.doc文件的用户分配给了system_u,文件类型分配给了httpd_t
小结
总之，通过以上操作就可以实现把文件无权限的scontext转换为有权限的scontext
最后用setenforce 1恢复此次会话的enforce模式，重启服务，发现文件能被成功访问了。
