开发环境用户能读取/etc/passwd，是因为其拥有FILE权限且secure_file_priv未设为NULL或未生效；FILE是独立全局权限，需显式回收并配合secure_file_priv=NULL（8.0.17+）或''（旧版）彻底禁用。
为什么开发环境用户还能读取 /etc/passwd
只要用户有 FILE 权限，且 secure_file_priv 没设为 NULL 或未生效，MySQL 进程就能用 LOAD DATA INFILE '/etc/passwd' 把系统文件内容读进表里——这和“能不能连上数据库”无关，只取决于权限+配置是否松动。
常见错误认知是：“我只是给了 SELECT 权限，他怎么还能读配置文件？” 实际上，FILE 是独立于表操作的全局权限，不随 SELECT 或 INSERT 一并授予或回收。
- 检查方式：
SELECT User,Host,File_priv FROM mysql.user WHERE File_priv='Y'; - 开发账号几乎从不需要
FILE，一旦发现为Y，就是配置疏漏 - 注意
root@localhost和root@%是两个账号，别只改了一个
彻底禁用导出能力：先撤权限，再锁路径
secure_file_priv 不是开关，只是白名单；它限制“能写到哪”，但不决定“能不能写”。真正起效的是收回 FILE 权限。
- 执行：
REVOKE FILE ON *.* FROM 'dev_user'@'localhost'; - 必须加
ON *.*，因为FILE是全局权限，不能作用于库或表 - 运行
FLUSH PRIVILEGES;立即生效（尤其在直接改过mysql.user表后） - 验证：用该用户登录后执行
SELECT 1 INTO OUTFILE '/tmp/test.txt';，应报ERROR 1045 (28000)
secure_file_priv 设为空字符串 '' 是最危险的配置
空字符串表示“不限制路径”，MySQL 完全跳过路径校验。哪怕你已回收 FILE 权限，某些旧版本（如 MySQL 5.6）在特定条件下仍可能绕过限制。
更糟的是，设为 /tmp 看似折中，实则埋雷：Linux 下 /tmp 全局可写，攻击者可提前放符号链接，让 MySQL 写入时覆盖关键文件（比如把 /tmp/my.cnf 指向 /etc/my.cnf）。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 生产与开发环境都应设为具体目录，例如
/var/lib/mysql-files - 该目录需由
mysql用户独占：sudo chown mysql:mysql /var/lib/mysql-files且chmod 750 - 设为
NULL最安全（完全禁用），但要求 MySQL ≥ 8.0.17，且启动时不报错
开发环境最容易被忽略的细节
Docker 部署时，即使配置了 secure_file_priv = /export，若没把宿主机目录挂载进去，MySQL 进程仍会因无写入权而静默失败；此时 INTO OUTFILE 报错是 Can't create/write to file，不是权限拒绝，容易误判。
另外，MySQL 8.0+ 支持 SET PERSIST secure_file_priv = NULL;，但该语句仅在支持持久化变量的版本生效，且仍需重启才能对已连接会话生效——所以开发环境建议直接改配置文件 + 重启，别依赖动态设置。
最后确认一点：禁止导出 ≠ 禁止访问数据。如果开发需要查敏感字段，应走脱敏视图或应用层加密，而不是开放 FILE 权限来“方便调试”。
