PostgreSQL基于角色的权限分层

PostgreSQL 的权限管理不是一张扁平的授权列表，而是一套基于“角色”层层嵌套、逐级传递的访问控制体系。很多开发者习惯直接给应用账号赋权，结果数据库里散落着几十个独立的用户，权限回收时根本理不清谁拥有什么。问题的根源在于没有理解 PostgreSQL 中“角色即用户、角色即组”的设计哲学，以及 LOGIN、INHERIT、NOINHERIT 这些属性如何影响权限的继承与隔离。真正落地的方案是：把权限赋予非登录角色，再将非登录角色授予登录角色，形成清晰的权限分层结构。

在 PostgreSQL 中，ROLE 是一个抽象概念，既可以代表一个数据库用户，也可以代表一个用户组。创建角色的语法只有 CREATE ROLE，CREATE USER 本质上只是带了 LOGIN 属性的 CREATE ROLE。这意味着你完全可以用同一个机制来管理“谁能登录”和“谁拥有什么权限”。关键属性有三个：LOGIN 决定角色能否建立连接；INHERIT 决定角色是否自动继承所属于其他角色的权限；BYPASSRLS 决定是否绕过行级安全策略。理解了这三个属性，就抓住了权限分层的核心。

当一个角色被 GRANT 给另一个角色时，被授予者就成为该角色的成员。默认情况下，成员会继承父角色的所有权限，这就是 INHERIT 行为。但如果你在创建角色时指定了 NOINHERIT，该角色虽然仍是父角色的成员，却不会自动获得父角色的权限——它必须在会话中显式执行 SET ROLE 来临时“激活”那个父角色身份。这个设计非常适合需要权限隔离的场景：比如一个数据分析师平时只有只读权限，只有在执行特定 ETL 任务时才切换到拥有写入权限的角色，从而避免误操作。

一个经过生产验证的分层模型是这样的：最底层是“全局只读角色”，拥有所有表上的 SELECT 权限；中间层是“业务读写角色”，在只读基础上增加 INSERT、UPDATE、DELETE 权限，但仅限于特定 schema 或表；最上层是“管理角色”，拥有 DDL 权限和角色管理权限。登录用户不直接拥有任何对象权限，而是被授予这些非登录角色中的一个或多个。当需要调整某个业务线的访问范围时，只需修改对应的业务角色，所有继承该角色的登录用户立即生效，无需逐个修改。

-- 创建非登录角色：全局只读
CREATE ROLE global_readonly NOLOGIN;
GRANT CONNECT ON DATABASE mydb TO global_readonly;
GRANT USAGE ON SCHEMA public TO global_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO global_readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO global_readonly;

-- 创建非登录角色：订单业务读写
CREATE ROLE order_rw NOLOGIN;
GRANT global_readonly TO order_rw;
GRANT INSERT, UPDATE, DELETE ON orders, order_items TO order_rw;

-- 创建登录用户并授予业务角色
CREATE ROLE alice LOGIN PASSWORD 'xxx' INHERIT;
GRANT order_rw TO alice;

上面的代码展示了分层授权的标准做法。注意 ALTER DEFAULT PRIVILEGES 的使用：它确保未来在 public schema 中新建的表也会自动被 global_readonly 访问，否则权限只对当前已存在的表生效。这是很多权限配置“莫名其妙失效”的常见原因。

PostgreSQL 在检查权限时，会遍历当前角色的所有直接权限和继承自父角色的权限。如果用户被设置了 NOINHERIT，这些父角色权限不会被自动计入，除非用户执行了 SET ROLE 命令。SET ROLE 本质上是在当前会话中切换“当前角色”的身份标识，从而让权限检查系统以该角色的视角来验证。更强大的用法是结合 SECURITY DEFINER 函数：创建一个函数，指定其 SECURITY DEFINER 属性，这样函数执行时将以函数拥有者的权限运行，调用者只需拥有函数的 EXECUTE 权限，而无需直接拥有底层表的访问权限。这是实现“最小权限原则”的经典手段。

-- 创建一个由特权角色拥有的函数
CREATE FUNCTION transfer_order_status(order_id int, new_status text)
RETURNS void LANGUAGE plpgsql SECURITY DEFINER
SET search_path = 'public'
AS $$
BEGIN
    UPDATE orders SET status = new_status WHERE id = order_id;
END;
$$;

-- 普通用户只需获得函数执行权限
GRANT EXECUTE ON FUNCTION transfer_order_status TO order_rw;

这个模式的价值在于：普通业务角色无法直接 UPDATE orders 表，但可以通过函数间接修改，而函数内部可以加入业务校验逻辑，形成一道可控的安全屏障。同时，SET search_path 子句防止了 search_path 注入攻击，这是编写 SECURITY DEFINER 函数时必须养成的习惯。

表级别的权限控制粒度仍然太粗，行级安全策略（RLS）可以将权限细化到数据行。RLS 策略本质上是为表附加一个布尔表达式，查询和修改操作会自动过滤不符合条件的行。当 RLS 与角色分层结合时，可以构建出极其灵活的数据隔离方案。比如在 SaaS 多租户系统中，每个租户的数据用 tenant_id 标识，全局只读角色看不到任何行，而各租户专属角色通过 RLS 策略只能看到自己租户的数据。策略的定义可以引用当前角色的成员关系，用 pg_has_role() 函数判断。

-- 启用行级安全
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

-- 策略：租户隔离
CREATE POLICY tenant_isolation ON orders
    USING (tenant_id = current_setting('app.current_tenant')::int);

-- 策略：管理员绕过
CREATE POLICY admin_bypass ON orders
    USING (pg_has_role('admin_role', 'MEMBER'));

这里用到了 current_setting 来获取应用设置的租户上下文，这要求应用在建立连接后执行 SET app.current_tenant = 'xxx'。多条策略之间是 OR 关系，只要满足其中一条即可访问该行。这意味着你可以叠加多个策略，让不同角色看到不同的数据子集，而无需修改应用代码中的 SQL 查询。

权限分层虽然强大，但回收权限时必须格外小心。PostgreSQL 的权限系统遵循“授予者回收”原则：只有最初授予权限的角色才能回收该权限。如果 DBA 用 superuser 身份 GRANT 了某个权限，后来想用业务管理角色去 REVOKE，会失败。另外，如果角色 A 被授予了角色 B，角色 B 又被授予了角色 C，那么 A 间接拥有了 C 的权限。当你想回收 A 对某个表的权限时，如果该权限是 C 授予的，你需要从 C 层面去回收，或者直接断开 A 与 B 的成员关系。这要求团队在规划角色层级时，必须明确每个权限的“授予源”，并文档化角色之间的依赖关系。

当角色嵌套达到三层以上时，肉眼追踪权限传递路径变得困难。PostgreSQL 的系统表提供了完整的元数据来审计。pg_roles 存储所有角色及其属性；pg_auth_members 记录角色之间的成员关系；information_schema.table_privileges 和 information_schema.role_table_grants 提供对象权限的详细视图。你可以编写递归查询来展开某个角色的完整权限继承树。

WITH RECURSIVE role_tree AS (
    -- 基础：直接成员关系
    SELECT r.rolname AS member, 
           g.rolname AS group_role,
           1 AS depth
    FROM pg_auth_members m
    JOIN pg_roles r ON r.oid = m.member
    JOIN pg_roles g ON g.oid = m.roleid
    WHERE r.rolname = 'alice'
    UNION ALL
    -- 递归：向上查找父角色的父角色
    SELECT rt.member,
           pg.rolname AS group_role,
           rt.depth + 1
    FROM role_tree rt
    JOIN pg_auth_members m ON m.member = (SELECT oid FROM pg_roles WHERE rolname = rt.group_role)
    JOIN pg_roles pg ON pg.oid = m.roleid
)
SELECT * FROM role_tree ORDER BY depth;

这段递归查询从 alice 这个登录角色出发，逐层向上追溯它所属于的所有角色，直到根节点。结合 table_privileges 视图，你可以精确定位 alice 对某张表的权限究竟来自哪个父角色、由谁在何时授予。这种审计能力是合规性检查的基础。

在实际落地中，混乱的角色命名会毁掉分层设计。建议采用“层级前缀”命名法：app_readonly 表示应用层只读角色，app_order_rw 表示订单模块读写角色，etl_transform 表示 ETL 转换角色，dba_admin 表示 DBA 管理角色。登录用户使用人名或服务名，如 svc_payment 或 analyst_zhang。所有权限只授予非登录角色，登录角色仅作为这些非登录角色的成员存在。禁止直接向登录角色 GRANT 对象权限，这条规则可以写入 CI/CD 的权限变更检查脚本中。同时，利用 DEFAULT PRIVILEGES 为每个 schema 设定新对象的默认权限，避免新表创建后出现权限真空。

权限分层不是一次性设计，而是随着业务演进而持续迭代的治理过程。当新的业务模块上线时，应该先定义对应的非登录角色及其权限边界，再将其授予需要访问的登录角色。当人员离职或转岗时，只需回收登录角色与业务角色之间的成员关系，而无需触碰底层对象权限。这种“一次配置、长期复用”的模式，才是 PostgreSQL 权限管理的正确打开方式。