高级运维工程师讲述银河麒麟V10SP1服务器加固收回权限/tmp命令引起生产MySql数据库事故实战

一、前言

作为运维工程师经常会对生产服务器进行安全漏洞加固，一般服务厂商、或者甲方信息安全中心提供一些安全的shell脚本，一般这种shell脚本都是收回权限，或者权限加固，或者删除某些漏洞的操作系统插件！笔者我，就最近由于服务器加固引起的生产事故总结一下，希望给大家一个惊醒！加固过程中，会引起生产事故！出了数据库事故，运维工程师躺枪背锅，笔者希望尽量避免，常在河边走，难免不湿鞋！笔者写这个文章，就是为了提前惊醒大家！避免跳坑，雷就在哪里，啥时候爆就是时间问题！如果出现数据库故障，可能对企业、产品的损失无法估量！

二、服务器环境介绍

uname -a
Linux localhost.localdomain 4.19.90-23.8.v2101.ky10.x86_64 #1 SMP Mon May 17 17:08:34 CST 2021 x86_64 x86_64 x86_64 GNU/Linux

cat /proc/version
Linux version 4.19.90-23.8.v2101.ky10.x86_64 (KYLINSOFT@localhost.localdomain) (gcc version 7.3.0 (GCC)) #1 SMP Mon May 17 17:08:34 CST 2021

cat /etc/os-release

NAME="Kylin Linux Advanced Server"
VERSION="V10 (Tercel)"
ID="kylin"
VERSION_ID="V10"
PRETTY_NAME="Kylin Linux Advanced Server V10 (Tercel)"
ANSI_COLOR="0;31"

三、核心脚本影响说明

chmod 750 /tmp   

权限回收会引起mysql数据库某些操作不正常！笔者也预测，对于postgre数据库也会影响！MYSQL用户与root不在一个组，导致750，其他组一点权限不给，那mysql用户没有权限操作/tmp目录！

mysql会报错：

引起某些数据库操作失败！比如建表、建立临时表、获取建表语句DLL、或者关系到主从集群同步！
原因是：

在 MySQL 中，/tmp 目录可能会被用于多种用途。例如，一些临时文件可能会被存储在 /tmp 中，以提高数据库操作的性能。例如，在执行复杂的查询或进行数据导入导出时，MySQL 可能会使用 /tmp 来存储临时数据。

然而，使用 /tmp 也存在一些潜在的问题。/tmp 目录通常是对所有用户可写的，这可能会导致安全风险。如果 MySQL 生成的临时文件没有得到适当的保护，其他用户可能能够访问或修改这些文件，从而导致数据泄露或数据库损坏。

为了减少这些风险，一些管理员可能会选择将 MySQL 的临时文件存储在一个更安全的位置，或者对 /tmp 目录进行更严格的权限控制。例如，可以设置只有 MySQL 进程能够访问和写入特定的临时文件目录。

总之，虽然 /tmp 在 MySQL 中可能会被使用，但需要注意相关的安全和性能问题，并根据实际情况进行适当的配置和管理。

解决方法：把mysql用户加在root组，或者就别回收/tmp权限！自己在测试服务器跑跑试试权限！直到那个权限报错不存在！

四、笔者简介

笔者简介
国内某一线知名软件公司企业认证在职员工：任JAVA高级研发工程师,大数据领域专家,数据库领域专家兼任高级DBA!10年软件开发经验！现任国内某大型软件公司大数据研发工程师、MySQL数据库DBA，软件架构师。直接参与设计国家级亿级别大数据项目!并维护真实企业级生产数据库300余个!紧急处理数据库生产事故上百起，挽回数据丢失所造成的灾难损失不计其数!并为某国家级大数据系统的技术方案（国家知识产权局颁布）专利权的第一专利发明人！

笔者想说几句额外的：
某程删库事故的巨大影响值得警醒！！当然笔者在文章中惊提醒某些企业高管资本家，如果公司对一线的运维、DBA不够尊重、重视！如果裁员涉及到DBA或者高级运维，那将会是灾难噩梦的开始，如果因为裁员裁到大动脉，核心数据丢失事故给企业、产品、社会的影响巨大损失无法估量！某程删库的事故损失情况，可以去网上查查！核心数据丢失了，老板、企业家们高管很可能赔满全部身价！所以笔者倡导作为企业家、高管对于一线的运维、DBA要给予更多的爱与尊重与认可！愿社会更美好，愿每一个一线工程师都获得尊重与认可！