数据库readonly用户角色切换权限差异咨询：是否预期及能否限制

这是预期设计吗？ #

是预期行为。核心原因在于PostgreSQL的会话权限机制：

• 直接以readonly用户登录时，会话的底层权限上下文完全基于readonly角色，而readonly本身没有切换到其他角色（包括superuser）的权限，所以执行SET ROLE或SET AUTHORIZATION会失败。
• 先以superuser登录再执行SET ROLE readonly时，只是临时切换了当前会话的用户标识，但会话的底层权限仍保留了初始superuser的权限属性——superuser本身拥有切换任意角色的权限，所以此时即便当前用户是readonly，依然能执行SET ROLE切回superuser。

能否限制这种行为？ #

可以，有两种实用方案：

方案1：使用SET SESSION AUTHORIZATION替代SET ROLE #

如果需要从superuser切换到readonly且限制其切回，不要用SET ROLE readonly;，而是执行：

SET SESSION AUTHORIZATION readonly;

这个命令会彻底重置会话的权限上下文，丢弃初始superuser的权限，此时当前会话的权限完全等同于直接以readonly登录的状态，无法再执行SET ROLE切换回superuser。

方案2：调整角色的继承属性 #

给readonly角色设置NOINHERIT属性，同时确保readonly没有被授予切换到superuser的权限：

ALTER ROLE readonly NOINHERIT;

当superuser执行SET ROLE readonly后，不会自动继承readonly的权限，结合权限设置可以进一步限制角色切换能力，但这种方式不如方案1彻底，最稳妥的还是使用SET SESSION AUTHORIZATION。

内容的提问来源于stack exchange，提问作者mar91