mysql备份文件权限控制本质是os层面问题，需通过限定运行用户、设置umask、严格目录权限（如750）、禁用明文密码及远程直传等方式保障安全。
MySQL备份文件本身没有权限控制机制
MySQL服务进程不管理mysqldump或mysqlpump生成的SQL文件，也不管xtrabackup产出的备份目录——这些只是普通操作系统文件。所以“MySQL如何限制备份文件读取”这个问题，本质是OS层面的权限问题，不是SQL语句或GRANT能解决的。
常见错误现象：mysqld进程以mysql用户运行，但备份脚本用root执行，结果备份文件属主是root，其他运维人员无法读取；或者备份目录开放了755，导致任意登录用户都能cat出CREATE USER语句和明文密码（如果没加--skip-dump-rows且表里存了凭证）。
- 备份命令必须明确指定输出用户和组，例如用
sudo -u backupuser mysqldump ... > /backup/db.sql - 输出路径的父目录需提前创建并设好权限：
chown backupuser:backupgroup /backup+chmod 750 /backup - 避免用
root直接跑备份：一旦误写mysqldump --all-databases到/tmp，临时文件可能被未授权用户访问
用umask和chmod控制新生成备份文件的默认权限
很多备份脚本依赖shell重定向（>）或gzip管道，这类操作受当前shell的umask影响。默认umask 022会导致文件权限为644，即世界可读——这在生产环境极危险。
使用场景：定时任务（crontab）中执行备份，但没显式设置umask，结果每天生成的.sql.gz都能被other用户zcat解出。
- 在备份脚本开头加
umask 027（组可读、其他不可读） - 对已生成文件补救：
find /backup -name "*.sql*" -exec chmod 640 {} \; -
gzip本身不继承umask，所以mysqldump | gzip > x.sql.gz仍会按父shell的umask建文件，但gzip -c file.sql > file.sql.gz则取决于gzip自身逻辑，行为不一致——统一用umask更可靠
禁止通过MySQL客户端直接导出到远程主机或共享目录
有人用mysqldump ... | ssh user@host "cat > backup.sql"，看似方便，实则绕过了本地文件权限管控：目标主机上的backup.sql由user创建，默认权限由对方umask决定，且传输过程无加密，中间节点可能截获。
错误示例：mysqldump --single-transaction db | nc remote 1234 —— 这种裸TCP传输既无认证也无加密，nc监听端若配置宽松，任何能连通的IP都可接收。
- 导出必须落盘在受控目录，再用
rsync --rsync-path="sudo rsync"推送到备份服务器（前提是目标机已配好免密sudo权限） - 禁用
LOCAL INFILE相关参数，防止恶意SQL通过LOAD DATA LOCAL INFILE反向读取客户端文件系统 - 如果必须用
ssh传输，加上-o StrictHostKeyChecking=yes并预置known_hosts，避免中间人劫持
备份脚本里别硬编码数据库密码，否则ps aux可见
执行mysqldump -u root -p123456 db时，密码会出现在进程参数里，任何普通用户执行ps aux | grep mysqldump就能看到。这不是备份文件权限问题，但直接导致备份行为本身泄露敏感信息。
性能/兼容性影响：用~/.my.cnf方式虽安全，但要注意该文件权限必须是600，否则mysqldump会拒绝读取（报错Warning: World-writable config file is ignored）。
- 正确做法：
echo "[client]\nuser=root\npassword=xxx" > ~/.my.cnf && chmod 600 ~/.my.cnf - 容器环境用
MYSQL_PWD环境变量也可，但要确保docker run --rm不把环境变量留在历史记录里 - 绝对不要在
crontab里写-p明文密码——cron日志可能被轮转保留，且ps可见性不变
真正麻烦的是跨团队协作时，备份权限常被当成“只要能跑通就行”的环节，结果/backup目录的chmod被反复覆盖，umask被不同shell解释器搞乱，最后靠人工巡检才发现某天的备份文件权限是644。这种事没法靠一次配置一劳永逸。
