MySQL物理拷库能绕过权限控制是因为其依赖文件系统层而非SQL层校验，datadir须设750权限且属主mysql:mysql，关键文件需chmod 640，备份目录必须物理隔离并由专用用户管理。
MySQL物理拷库为什么能绕过权限控制
因为mysqld进程本身不校验数据文件的访问来源——只要操作系统允许读取ibdata1、.ibd等文件，攻击者或误操作者就能直接复制整个datadir目录，拿到完整数据库快照。这和SQL层的SELECT权限、用户密码完全无关，是文件系统层的失控点。
datadir目录权限必须设为750且属主为mysql:mysql
这是防物理拷库的第一道硬隔离。750意味着：只有mysql用户可读写执行，同组用户（如运维组）只能进入和列出内容，其他用户彻底无权访问。
- 查当前
datadir路径：mysql -e "SHOW VARIABLES LIKE 'datadir';" - 确认
mysqld运行用户：ps aux | grep mysqld | grep -v grep，常见为mysql或mysqld - 重置所有权：
sudo chown -R mysql:mysql /var/lib/mysql（路径按实际输出替换） - 设置目录权限：
sudo chmod 750 /var/lib/mysql（注意：只改目录本身，内部文件由MySQL管理，不手动chmod） - 禁止上级目录宽松：确保
/var/lib权限≤755，防止路径遍历绕过
关键文件权限要细化到640，不能只靠目录锁
即使datadir是750，如果ibdata1或mysql/user.MYD这类文件权限是644甚至666，有组写权限的账号仍可能覆盖或删改——尤其当运维组成员被提权后。
- 批量修正数据文件权限：
find /var/lib/mysql -type f -name "*.ibd" -o -name "ibdata1" -o -name "*.frm" -exec chmod 640 {} \; - 检查
mysql系统库文件：ls -l /var/lib/mysql/mysql/，确保user.MYD、db.MYD等都是mysql:mysql且权限≤640 - 特别注意日志文件：
log_error、slow_query_log_file也需chmod 640，否则可能泄露SQL语句或连接信息
备份目录必须与datadir物理隔离+专用用户锁定
很多人把mysqldump结果或XtraBackup输出直接丢进/var/lib/mysql/backup/，等于把钥匙和锁放一起——一旦datadir被突破，备份也一并沦陷。
- 备份目录必须独立挂载或位于不同分区，例如
/backup/mysql/ - 用专用系统用户运行备份脚本，比如
backupuser，而非root或mysql - 设置归属：
sudo chown -R backupuser:backupgroup /backup/mysql - 权限严格为750：
sudo chmod 750 /backup/mysql - 备份脚本本身（如
/usr/local/bin/backup-mysql.sh）也要chown backupuser:backupgroup+chmod 750
真正卡点永远在「谁创建了这些文件」和「谁还能删改它们」——漏掉任意一个，物理拷库就只是时间问题。
