MySQL 角色权限为什么仍会越权：partial revokes、默认角色与验收边界

不少人在MySQL里用上角色做权限隔离后，还是遇到账号能访问未授权表的越权问题，这基本不是角色功能本身出故障，而是整个授权链路没有按照实际运行的会话状态做验收：默认角色有没有自动启用、早年留下的通配符权限是不是覆盖了刚新建的库、之前直接给账号授的权限有没有绕开角色的边界限制，这些问题都会让你设计文档里写的最小权限完全落不了地。

先界定要保护的资产：表、库还是实例级能力

权限审查的起点不是“这个用户属于哪个角色”，而是列出用户真正能触达的资产。以报表账号为例，允许读取 sales.orders 并不意味着它可以读取同库的 sales.customers，更不意味着它需要 CREATE、FILE 或全实例范围的管理能力。

可以先梳理出一张需求对照表，把业务侧的权限要求翻译成数据库侧的授权规则，下面的权限范围特意收得很窄：报表账号只能只读访问订单相关表，数据导入账号只能写staging临时表，只有运维账号才能拿到结构变更的权限。

攻击路径：默认角色和通配符怎样叠加出越权

角色权限会在登录后加载到当前会话里，但“数据库里存在这个角色”和“当前会话已经启用这个角色”是完全两码事。一个用户可能同时绑定了默认角色、非默认角色，还有早年直接授予账号的零散权限；应用连接池复用旧连接的时候，还会让排查的人误以为刚做完的授权变更已经生效。

先新开一个专用的审查会话来排查用户和角色状态，不要凭之前的印象下判断：

SHOW GRANTS FOR 'report_reader'@'%';
SHOW GRANTS FOR 'role_report_reader';
SELECT USER(), CURRENT_USER(), CURRENT_ROLE();

SHOW GRANTS FOR 看到的是授权声明，CURRENT_ROLE() 反映的是当前会话启用的角色。两者不一致时，先检查默认角色配置和连接初始化语句；不要直接把所有权限重新授给用户。

风险分级：把“能查到”与“能改变”分开

权限问题不要简单归成“安全/不安全”两类。能读到同库里的非目标表属于数据暴露风险，能修改正式业务表属于数据完整性风险，能创建自定义函数、写服务器文件或者管理其他账号，就已经能直接接管整个数据库实例了。把风险分级之后，修复的先后顺序会非常清晰。

• P0：普通业务账号能写入正式订单、删除数据或者管理其他账号，先直接撤掉扩大范围的违规授权，再恢复业务运行。
• P1：只读账号能读取同库敏感表，优先拆分对应角色和业务连接账号，只保留最小可用的查询权限。
• P2：数据库里存在没人使用的非默认角色或者历史遗留授权，先把依赖关系记录清楚，再在预定的变更窗口里清理掉。

尤其要留意 *.*、sales.* 这类范围。它们会随着数据库或表的增加而扩大影响面，权限审查不能只对着今天已有的表做快照。

防护控制：用角色收敛范围，再用 partial revokes 做过渡

长期优化思路是把应用账号身上的直接权限压到最低，把可以复用的权限拆成用途单一的角色，再给账号明确绑定对应的默认角色。示例操作先创建独立角色，再给角色只授予目标表的对应权限：

CREATE ROLE 'role_report_reader';
GRANT SELECT ON `sales`.`orders` TO 'role_report_reader';
GRANT 'role_report_reader' TO 'report_reader'@'%';
SET DEFAULT ROLE 'role_report_reader' TO 'report_reader'@'%';

如果历史系统已经有数据库级通配符授权，MySQL 的 partial_revokes 可以在特定场景下对其中一部分库或对象做收窄。它适合迁移期间降低暴露面，不适合掩盖角色边界混乱：不同版本、启用方式和授权范围都必须在目标环境验证，不能把文档里的示例当成通用开关。

迁移时建议先保存当前授权结果，再在一条变更中完成收窄和新角色绑定。若应用突然出现权限错误，回滚应恢复原授权声明，而不是临时给账号追加一个更大的 *.*。

审计记录：记录谁在什么会话里获得了什么权限

一份可以复查的权限变更记录，至少要包含账号名、匹配的访问主机、绑定角色、授权范围、默认角色配置、操作人和对应的回滚语句。对接连接池的应用，还要记录连接初始化完成后的实际生效角色，同一个账号在不同会话里拿到的有效权限可能完全不一样。

SELECT USER(), CURRENT_USER(), CURRENT_ROLE();
SHOW GRANTS FOR 'report_reader'@'%';
SHOW GRANTS FOR 'role_report_reader';

不要拿测试账号直接连生产业务库随便试效果。提前准备一组只包含必要字段的验收测试表，分别验证目标查询操作、非目标查询操作、写入操作、建表操作和导出路径权限，所有测试结果和变更单一起存档留存。

验证清单：新会话和回滚都通过才算收敛

1. 关闭旧连接池连接，使用全新会话确认 CURRENT_ROLE() 与预期一致。
2. 执行一条允许的 SELECT，确认目标表可读、敏感表不可读。
3. 分别验证 INSERT、UPDATE、CREATE 和文件相关能力，确认拒绝原因符合预期。
4. 移除默认角色后重新登录，确认非默认角色不会自动恢复未授权的访问权限。
5. 在预演环境执行回滚SQL，再用同一组测试用例验证旧权限状态和连接池重建后的表现。

如果“拒绝”只发生在旧连接，而新连接又能访问，说明连接初始化或默认角色配置仍有问题；如果 SHOW GRANTS 看起来很窄但查询仍成功，要继续查直接授权、代理用户和对象级权限。

相关问题：权限边界最容易漏在哪里

只撤销角色，为什么账号仍然能查表？

因为账号可能保留了直接授予的权限，或者当前连接仍在使用旧的有效角色。先查 SHOW GRANTS FOR 用户，再断开并重建会话。

partial revokes 能不能替代最小权限设计？

不能。它更适合用来收窄遗留的通配符授权，新上线的系统最好从表级或者更小粒度的角色授权开始规划。

连接池为什么会让权限修复看起来没有生效？

连接池可能会保留旧会话和旧的角色状态，权限变更完成后要主动回收旧连接、新建会话，把实际生效角色的查询逻辑加到应用健康检查或者发布验收流程里。

MySQL角色权限的安全边界，最终要落到“新建会话实际能执行什么操作”上。把资产范围、风险路径、风险级别、收敛措施和回滚证据都放到同一份变更记录里，才不会因为一次没注意的通配符授权或者连接池复用，让做好的最小权限配置重新失效。