必须服务端和客户端双侧禁用local_infile，仅看配置或变量值不够，需实测SELECT @@local_infile返回0且LOAD DATA LOCAL INFILE '/etc/passwd'报ERROR 1148才算真正生效。
怎么确认local_infile是否真被禁用
只看my.cnf或执行SHOW VARIABLES LIKE 'local_infile'不够——它可能返回OFF，但客户端连接时仍能绕过。必须实测两件事：SELECT @@local_infile返回0，且LOAD DATA LOCAL INFILE '/etc/passwd' INTO TABLE t报错ERROR 1148 (42000)。如果报ERROR 2068，说明客户端和服务端都拦住了；如果成功或报权限错误，说明某一层漏了。
服务端配置必须写对位置并重启
local_infile = OFF必须加在[mysqld]段下，不是[mysql]或[client]。写错段落等于没配。常见错误包括：
- 把
local_infile = OFF写进[mysql]段——这是客户端工具默认行为，不影响服务端接收能力 - 配置文件路径不对：CentOS 通常用
/etc/my.cnf，Ubuntu/Debian 多是/etc/mysql/mysql.conf.d/mysqld.cnf - 改完没重启：
sudo systemctl restart mysql（或mariadb），reload不生效 - Docker 容器里没挂载新配置，或启动命令覆盖了配置（比如
docker run --rm -e MYSQL_ROOT_PASSWORD=... mysql:8.0没传my.cnf）
客户端连接时必须显式关闭local_infile
服务端关了，客户端还开着，攻击者就能通过注入让应用“主动发起”本地读取。不同客户端关闭方式不一样：
- MySQL CLI：
mysql --local-infile=0 -u user -p，不能依赖~/.my.cnf里[client]段的local-infile = 0——有些版本忽略它 - PyMySQL：
pymysql.connect(..., local_infile=False)，漏掉这个参数就白配 - PHP mysqli：
mysqli_options($conn, MYSQLI_OPT_LOCAL_INFILE, false)必须在mysqli_real_connect()之前调用 - Java Connector/J 8.0+：
&allowLoadLocalInfile=false要写在 JDBC URL 里，且不能被&allowLoadLocalInfile=true覆盖
别漏掉secure_file_priv和FILE权限这两层
local_infile = OFF只管LOAD DATA LOCAL INFILE，不管服务端自己读文件。真正防服务器本地文件泄露，还得做两件事：
-
secure_file_priv = NULL写进[mysqld]段并重启，验证SELECT @@secure_file_priv返回NULL；设为空字符串''等于完全放开路径 -
REVOKE FILE ON *.* FROM 'user'@'host'，特别检查root账号：SELECT User,Host,File_priv FROM mysql.user WHERE File_priv='Y' - 验证：
LOAD DATA INFILE '/etc/passwd' INTO TABLE t应报ERROR 1290，SELECT LOAD_FILE('/etc/passwd')应返回NULL或明确权限拒绝错误
托管环境（RDS、Docker、K8s）最容易漏检——参数组改了没点“应用”，initContainer 覆盖了主配置，或者镜像自带的entrypoint动态重写了local_infile。安全不是配一次就完事，是每次部署后都得跑一遍SELECT @@local_infile和LOAD DATA LOCAL INFILE实测。
