撤销FILE权限必须用REVOKE FILE ON . FROM 'user'@'host'并执行FLUSH PRIVILEGES，界面无该选项；需验证SHOW GRANTS无FILE且SELECT...INTO OUTFILE报错，并同步配置secure_file_priv。
撤销 FILE 权限必须用 REVOKE，界面勾选无效
phpMyAdmin 的权限编辑界面（「用户账户」→「编辑权限」）根本不提供 FILE 权限的勾选项——它只显示数据、结构、管理类权限，FILE 属于服务器级全局权限，不在该界面暴露。试图在「全局权限」里找 FILE 复选框只会白费时间。
必须通过 SQL 执行 REVOKE，且目标必须是 ON *.*，不能限定到某个库或表：
REVOKE FILE ON *.* FROM 'user'@'host';- user 和 host 必须和
SHOW GRANTS FOR 'user'@'host';输出完全一致（包括引号、大小写、IP 段通配符） - 执行后必须跟
FLUSH PRIVILEGES;，否则已建立的连接仍可使用 FILE 权限
FILE 权限残留的常见表现和验证方式
撤销后用户仍能执行 SELECT ... INTO OUTFILE 或 LOAD DATA INFILE，大概率是以下三种情况之一：
- 没执行
FLUSH PRIVILEGES;，缓存未刷新 - 用户有多个 host 记录（如
'user'@'localhost'和'user'@'10.20.%'），只 revoke 了其中一个 - MySQL 配置中
secure_file_priv被设为空或宽松路径（如/var/lib/mysql-files/），导致即使无 FILE 权限，某些绕过手段仍可能生效
验证是否真正清除：运行 SHOW GRANTS FOR 'user'@'host';，输出里不应出现 FILE 字样；再试 SELECT 'test' INTO OUTFILE '/tmp/test.txt';，应报错 ERROR 1290 或 ERROR 1045。
为什么不能直接改 mysql.user 表的 FILE_priv 字段？
手动更新 mysql.user 表的 FILE_priv 字段为 'N' 理论上可行，但风险极高：
- MySQL 5.7+ 中，直改系统表后不执行
FLUSH PRIVILEGES;，新权限对新连接无效 - 若表结构变更（如 MySQL 8.0+ 的字段名改为
File_priv，且大小写敏感），UPDATE 语句会静默失败 - 误操作可能破坏其他字段（如
authentication_string），导致用户彻底无法登录
REVOKE 是原子操作，语义明确，出错会立即报错，比手改表安全得多。
撤销 FILE 后还要同步检查 secure_file_priv
FILE 权限只是开关，secure_file_priv 才是实际限制范围。即使撤了 FILE，若该变量值为空（''）或为 '/'，攻击者仍可能利用其他漏洞写入关键路径。
务必确认：
- MySQL 配置文件（
my.cnf）中设置了secure_file_priv = /tmp/或更严格的路径 - 重启 MySQL 后，运行
SELECT @@secure_file_priv;返回预期路径，而非NULL或空字符串 - phpMyAdmin 的
config.inc.php中清空了$cfg['SaveDir']（防止导出功能间接利用 FILE）
FILE 权限本身不常被业务需要，一旦启用就等于把服务器文件系统大门敞开一条缝——撤销动作必须连同配置、缓存、验证三者闭环，缺一不可。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
