为什么MySQL中授予PROCESS权限会泄露敏感SQL-mysql教程-PHP中文网

PROCESS权限不写日志但使敏感SQL明文暴露在SHOW PROCESSLIST和performance_schema.threads中，易因应用错误处理导致泄露；REVOKE后用户仍可见自身线程属正常设计；推荐用受限视图替代直接授权。

为什么mysql中授予process权限会泄露敏感sql

PROCESS权限本身不写日志，但会让敏感SQL暴露在SHOW PROCESSLIST里

MySQL 的 PROCESS 权限不会直接导致错误日志或慢日志记录敏感 SQL，但它允许用户执行 SHOW PROCESSLIST 或查询 performance_schema.threads，而这两处会明文显示正在运行的 SQL 语句——包括含身份证、手机号、密码字段的 SELECT/UPDATE，甚至带参数值的 WHERE 条件。

一旦应用层错误处理不当（比如把 PROCESSLIST 输出拼进异常日志、监控告警或调试页面），这些 SQL 就会流到外部系统，形成间接泄露链。

哪些场景下PROCESS权限最危险

应用后台定时采集线程信息做“慢 SQL 排查”，结果把整条 SELECT * FROM users WHERE id = '12345' AND phone = '138****1234' 写进自己的业务日志文件
运维脚本用 mysql -e "SHOW PROCESSLIST" | grep -i password 检查风险语句，但输出未脱敏且被上传至共享目录
前端监控面板调用 API 查询 performance_schema.threads 并直接渲染 SQL 文本，未过滤敏感字段名或值
低权限账号被钓鱼获取 shell 后，用已有 PROCESS 权限连上数据库，手动执行 SHOW PROCESSLIST 扫描当前活跃查询

REVOKE PROCESS后仍能看到自己线程？这是正常行为

MySQL 默认允许用户查看自己的线程（即 SHOW PROCESSLIST 中只显示本用户发起的连接），无需 PROCESS 权限。所以即使执行了 REVOKE PROCESS ON *.* FROM 'app_user'@'%'，该用户仍能看到自己发的 SQL —— 这不是漏洞，是设计使然。

真正要防的是跨用户窥探。确认回收生效的方法是：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

用 app_user 登录，执行 SHOW PROCESSLIST，检查输出是否只含自身连接（User 列全为 app_user）
执行 SELECT COUNT(*) FROM performance_schema.threads WHERE PROCESSLIST_USER != 'app_user'，结果应为 0
运行 SHOW GRANTS FOR 'app_user'@'%'，确保输出里没有 PROCESS

替代方案：用受限视图代替直接授权PROCESS

如果业务真需要“看线程”能力（如排查阻塞），又不想放开 PROCESS，可建一个受限视图，只暴露必要字段且过滤敏感内容：

CREATE VIEW app_processlist AS
SELECT 
  ID,
  USER,
  HOST,
  DB,
  COMMAND,
  TIME,
  STATE,
  LEFT(INFO, 200) AS INFO_TRIMMED  -- 截断 SQL，避免长查询暴露完整条件
FROM performance_schema.threads
WHERE USER = USER();

然后只授予 SELECT 权限给该视图：GRANT SELECT ON mydb.app_processlist TO 'app_user'@'%'。这样既满足可观测性，又切断了跨用户窥探路径。

注意：视图无法隐藏 INFO 字段中已存在的敏感值，所以关键还是得靠应用层避免在 SQL 中拼接明文数据——比如用参数化查询，而不是 CONCAT("WHERE phone = '", user_input, "'")。