mysql中禁止数据库用户执行数据导入与导出操作

彻底禁用导入导出能力须撤回全局FILE权限：执行REVOKE FILE ON . FROM 'user'@'host';、FLUSH PRIVILEGES;，并检查角色继承；secure_file_priv仅限路径，不能替代权限回收。

为什么 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 权限还在，任何配置或中间层策略都存在被绕过的可能。