MySQL通过secure_file_priv限制SELECT ... INTO OUTFILE路径，设为NULL则禁用，空字符串''最危险；必须设为专用目录并重启生效，同时回收FILE权限以阻断提权链。
MySQL禁止用户用SELECT ... INTO OUTFILE写文件到任意路径
默认情况下，只要用户有FILE权限，就能通过SELECT ... INTO OUTFILE把查询结果写到服务器任意可写路径（比如/var/lib/mysql-files/之外的/tmp或/etc），这是典型的数据导出滥用入口。
真正起作用的是secure_file_priv系统变量——它不是开关，而是路径白名单。MySQL只允许INTO OUTFILE和LOAD DATA INFILE操作落在该变量指定的目录内。
- 检查当前值：
SELECT @@secure_file_priv;，返回NULL表示完全禁用，空字符串''表示不限制（极度危险） - 生产环境必须设为具体目录，例如
/var/lib/mysql-files/，且确保该目录仅MySQL用户可写、其他用户不可读 - 修改需在
my.cnf中设置：secure_file_priv = /var/lib/mysql-files，然后重启mysqld（动态SET不生效） - 注意：设为
/var/lib/mysql-files/后，用户仍能执行INTO OUTFILE，但只能写到该目录下——所以还要配合文件系统权限收紧
如何彻底回收FILE权限防止提权
FILE权限本身不涉及数据库表数据，但它能读取服务器本地文件（如LOAD DATA INFILE '/etc/passwd'），还能配合SELECT ... INTO OUTFILE写Webshell或覆盖配置文件，在提权链里是关键一环。
除非业务明确需要导入导出（如ETL任务），否则应直接回收。回收后，即使secure_file_priv配置宽松，攻击者也无权触发相关操作。
- 回收命令：
REVOKE FILE ON *.* FROM 'username'@'host'; - 检查残留：
SELECT User,Host,File_priv FROM mysql.user WHERE File_priv='Y'; - 特别注意root用户：很多运维习惯性给root开全权限，但
FILE对管理账号并非必需，建议单独剥离 - 应用账号几乎从不需要
FILE，回收后如果报错ERROR 1045 (28000): Access denied; you need (at least one of) the FILE privilege(s) for this operation，说明代码里误用了INTO OUTFILE，该改逻辑而非开权限
为什么secure_file_priv设为空字符串比设为/tmp更危险
空字符串''代表“不限制路径”，MySQL完全不校验输出位置——此时哪怕回收了FILE权限，某些旧版本（如5.6）在特定条件下仍可能绕过限制。
而设为/tmp看似方便，实则埋雷：Linux下/tmp通常全局可写，任何用户都能创建文件；攻击者可提前放一个符号链接，让MySQL写入时实际覆盖关键文件（如/tmp/my.cnf指向/etc/my.cnf）。
- 绝对不要设为空字符串，这是MySQL最危险的默认值之一（部分发行版仍保留）
-
/tmp也不安全，优先选MySQL专用目录，如/var/lib/mysql-files/（Debian/Ubuntu默认）或/usr/local/mysql/files/（源码安装） - 目录需由
mysql用户专属拥有：chown mysql:mysql /var/lib/mysql-files，且权限设为750（禁止组和其他人写入）
应用层写文件需求该怎么替代INTO OUTFILE
开发常依赖INTO OUTFILE做报表导出或日志备份，但这本质是把数据库当文件服务器用，既不安全又难审计。
正确做法是把数据查出来，由应用进程自己写文件——这样路径可控、权限隔离、还能加签名和压缩。
- PHP示例：
$result = $pdo->query("SELECT * FROM orders WHERE created_at > '2024-01-01'"); file_put_contents('/app/export/orders.csv', $csvContent); - Python示例：
df.to_csv('/app/export/report.csv', index=False)，路径由应用配置控制，不经过MySQL - 关键区别：应用写文件走的是应用用户权限（如
www-data），与MySQL用户完全隔离；即使应用被攻破，也拿不到MySQL文件目录写权限 - 如果必须用MySQL导出（如大数据量避免内存溢出），至少确保目标路径在
secure_file_priv范围内，并由定时任务立即挪走+清理
最易被忽略的一点：secure_file_priv配置后必须重启MySQL，且FILE权限回收要针对每个host组合单独执行（'user'@'10.0.0.%'和'user'@'localhost'是两个不同账号）。漏掉任意一个，都可能成为突破口。
