必须直接查询mysql.user表的File_priv字段是否为'Y'，因其不显示在SHOW GRANTS中；再结合@@secure_file_priv值（NULL/空字符串/具体路径）及UDF插件存在情况综合评估风险。
查 mysql.user 表的 File_priv 字段是否为 'Y'
MySQL 的文件写入权限（FILE）是全局权限，只在 mysql.user 表中体现，字段名为 File_priv，值为 'Y' 或 'N'。它不随数据库或表变化，也不出现在 SHOW GRANTS 的语句结果里——哪怕你执行过 GRANT FILE ON *.* TO ...，SHOW GRANTS 也**不会显示**这个权限，这是最容易被忽略的关键点。
必须直接查表：
SELECT User, Host, File_priv FROM mysql.user WHERE File_priv = 'Y';
注意：File_priv 是 enum 类型，不能写成 = 1 或 IS TRUE；大小写敏感，必须用单引号包裹 'Y'。
结合 secure_file_priv 配置判断实际风险等级
有 File_priv = 'Y' 只是“能写”的前提，真正能否落地写文件，还取决于 secure_file_priv 的值。这个变量像一道闸门：
- 若
@@secure_file_priv返回NULL：所有SELECT ... INTO OUTFILE和LOAD DATA INFILE操作直接报错，此时File_priv = 'Y'几乎无害（但仍是隐患，重启或配置变更后可能激活） - 若返回空字符串
''：MySQL 5.7+ 中部分版本会退化为“不限制路径”，等效于高危开放状态 - 若返回具体目录（如
/var/lib/mysql-files/）：权限受限，但仍需检查该目录是否被 Web 服务可访问、是否属主为mysql、权限是否为750
查配置命令：
SELECT @@global.secure_file_priv;
警惕 SHOW GRANTS 不显示 FILE 权限的误导性
运行 SHOW GRANTS FOR 'u'@'h' 后没看到 FILE，不代表用户没这个权限。原因有二：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
-
FILE权限永远不会出现在SHOW GRANTS输出中，这是 MySQL 的硬性设计 - 如果该用户是通过角色（role）继承来的
FILE，SHOW GRANTS会显示角色名，但不会展开角色内含的FILE—— 你得再查mysql.role_edges和对应角色的mysql.user记录
所以，只要怀疑某账号有文件操作能力，就绕过 SHOW GRANTS，直查 mysql.user 表 + @@secure_file_priv。
确认是否存在可被利用的 UDF 或插件扩展
有些攻击者不走 INTO OUTFILE，而是通过安装 UDF（如 sys_exec）执行系统命令。这类行为不依赖 File_priv，但需要 SUPER 或动态加载权限。
快速排查：
SELECT name, type FROM mysql.func WHERE name LIKE '%sys%';
SELECT plugin_name, plugin_status FROM information_schema.plugins WHERE plugin_name LIKE '%sys%';
若有结果，说明已存在高危扩展函数或插件，即使 File_priv = 'N'，仍可能被用于写文件或提权。
真正危险的不是“有没有 FILE 权限”，而是“谁有 FILE 权限 + 其 host 是否为 '%' + secure_file_priv 是否指向宽松路径 + 是否残留 UDF”。四个条件任意满足两个，就该立即处置。
