为什么 LOAD DATA
和 SELECT ... INTO OUTFILE
会绕过常规权限控制
MySQL 的数据导入导出操作（如
LOAD DATA INFILE、
SELECT ... INTO OUTFILE）不依赖普通表级权限（如
SELECT或
INSERT），而是由两个独立全局权限控制：
FILE权限。只要用户拥有该权限，就能从服务端文件系统读写任意可访问路径（受
secure_file_priv限制）。这意味着即使你已收回所有数据库操作权限，只要没显式撤销
FILE，用户仍可能通过文件读写泄露或篡改数据。
如何彻底禁用用户的导入导出能力
核心是移除
FILE权限，并确认其无法被重新授予。操作分三步： 执行
REVOKE FILE ON *.* FROM 'username'@'host';—— 注意必须是
ON *.*，因为
FILE是全局权限，不能作用于单库或单表 运行
FLUSH PRIVILEGES;确保权限立即生效（尤其在直接修改
mysql.user表后） 检查是否仍有隐式继承：若用户属于角色（MySQL 8.0+），需同时从角色中撤回
FILE，或确保该角色本身未被授予
FILE
验证方式：以该用户登录后执行
SELECT ... INTO OUTFILE '/tmp/test.txt';，应报错
ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement或更明确的
ERROR 1045 (28000): Access denied for user ... (using password: YES)（后者说明
FILE已失效）。
secure_file_priv
不是替代方案，只是辅助防线
设置
secure_file_priv='/var/lib/mysql-files'只能限制读写路径范围，不能禁止操作本身。只要用户有
FILE权限，仍可在该目录下读取配置文件、写入 Webshell（若 Web 目录可被该路径覆盖）、或导出敏感表结构。它解决的是“能读哪”，而非“能不能读”。因此： 不要依赖
secure_file_priv来代替权限回收 若业务完全不需要导入导出，建议设为
secure_file_priv=''（空值）或
NULL（MySQL 8.0.17+），此时所有
LOAD DATA和
INTO OUTFILE语句直接报错，但前提是
FILE权限也已被撤回，否则启动时会失败 修改此变量需重启 MySQL 或使用
SET PERSIST secure_file_priv = '';（仅限支持持久化变量的版本）
应用连接池或中间件场景下的隐藏风险
很多应用使用连接池（如 HikariCP、Druid）或 SQL 中间件（如 ProxySQL、ShardingSphere），它们常以高权限账号建连，再通过会话级变量或注释模拟用户上下文。此时即使业务用户无
FILE权限，攻击者若能注入 SQL，仍可能利用连接池持有的高权限执行
LOAD DATA。应对方式： 连接池使用的数据库账号必须严格遵循最小权限原则，明确不授予
FILE在中间件层配置 SQL 黑名单，拦截含
LOAD DATA、
INTO OUTFILE、
DUMPFILE的语句（注意大小写和空格绕过） 审计日志中重点关注
Com_load和
Com_select中带
INTO OUTFILE的查询（可通过
general_log或
slow_query_log配合正则提取）
SELECT argument FROM mysql.general_log WHERE command_type = 'Query' AND argument LIKE '%INTO OUTFILE%' ORDER BY event_time DESC LIMIT 5;
真正起效的永远是权限回收，其他都是补丁。只要
FILE权限还在，任何配置或中间层策略都存在被绕过的可能。
