如果管理过任何一套正经的 PostgreSQL你大概率遇到过两种经典场面一是新同事在测试库上死活查不着一张表你在工位上一看就知道是权限没给到位二是上线前夜有人来问某个账号为啥能碰生产库的数据。两个问题指向同一个根源——账号与权限体系没有理顺。PostgreSQL 的用户与权限管理在圈内以灵活著称但灵活的背面就是复杂。它不像 MySQL 那样有 userhost 这种相对直观的授权模型而是把用户、角色、成员关系、对象权限、默认权限、行级安全叠在一起新手第一次接触很容易绕晕。这篇是 PostgreSQL 16 系列里专门讲用户与权限管理的一篇内容包括基础概念、语法拆解、实战案例以及我从 PG15 升到 PG16 之后在权限方面踩过的坑。适合刚接触 PostgreSQL 的同学建立完整认知也适合有一定经验但平时主要写业务 SQL、很少系统梳理权限体系的开发同学查漏补缺。我会尽量把每个知识点都写清楚为什么这样做而不只是给一段能跑的命令。1. 权限体系概览先搞清角色、用户和授权的关系很多人第一次被 PostgreSQL 绕住就是因为它没有一个独立的用户概念。在 MySQL 里用户就是登录账号和库、表是分开的在 PostgreSQL 里用户和角色本质上是一个东西——用户就是带有 LOGIN 属性的角色。这个设计在早期看起来反直觉但真正理解之后会发现它非常强大因为你可以把一个角色当作权限集合来用再把这个集合交给别的角色实现权限的批量管理。1.1 用户和角色在 PostgreSQL 里是同一个实体先记住一句话PostgreSQL 中的 ROLE 既可以是一个人登录账号也可以是一个组权限集合。系统表 pg_authid 里存的就是所有角色你在 psql 里执行\du看到的列表就是它们。创建的时候CREATE ROLE和CREATE USER几乎等价唯一的区别是CREATE USER会默认带上 LOGIN 属性而CREATE ROLE默认不带。也就是说CREATE USER alice; -- 等价于 CREATE ROLE alice WITH LOGIN;所以后面讲角色属性时你不用把用户和角色当成两个东西只需要区分某个角色是不是允许登录LOGIN以及它被授予了哪些权限。1.2 授权的层级集群、数据库、Schema、对象PostgreSQL 的权限不是一条 GRANT 走天下而是分层的。从大到小大致是集群级能否连接、能否创建数据库、是否超级用户等由角色属性控制。数据库级CONNECT、CREATE、TEMPORARY。Schema 级USAGE能不能用这个 schema 里的对象、CREATE能不能在里面建对象。对象级表、视图、序列、函数等各自有各自的权限集合。这个层级最容易踩的坑是很多人只给用户授了表的 SELECT却忘记授 Schema 的 USAGE结果查询时报permission denied for schema public。权限检查是从外层往内层走的外层的门没开里层的钥匙再多也没用。1.3 拆解一条 GRANT 语句先看一条最简单的授权GRANT SELECT ON TABLE public.orders TO app_rw;这条语句拆开来看包含四个要素GRANT 关键字、权限类型SELECT、对象public.orders、被授权者app_rw。如果再加上 WITH GRANT OPTION就意味着这个用户拿到权限后还可以把这个权限转授给别人。别小看这个选项很多权限失控就出在它上面——被授权者可以把自己拥有的权限继续扩散而回收时往往需要级联处理。到这里权限体系的大框架就清楚了。接下来我们从账号管理的生命周期开始把每一步操作都过一遍。2. 账号管理实操从创建角色到安全删除用户和权限管理的第一课永远是账号怎么建、怎么改、怎么删。2.1 创建角色CREATE ROLE 的完整姿势创建一个用于业务系统的登录账号最少要指定密码和登录权限CREATE ROLE app_rw WITH LOGIN PASSWORD strong_password_here;如果你不想让这个角色能登录就建一个组角色用来收拢权限CREATE ROLE app_readonly_role;组角色不设 LOGIN不接业务只作为权限的载体。然后你把具体用户挂到这个组下面GRANT app_readonly_role TO alice;这样 alice 就自动继承了 app_readonly_role 拥有的所有权限。以后想调整一批账号的权限只需要改组角色的授权关系不需要逐个账号 GRANT。2.2 角色属性逐个说清楚除了 LOGIN 和 PASSWORD角色还有很多属性我列一个常用表属性含义使用建议SUPERUSER超级用户绕过一切权限检查生产环境不要给业务账号CREATEDB允许创建数据库只给 DBA 类角色CREATEROLE允许创建和管理角色只给 DBA 类角色REPLICATION复制账号专用只在搭建流复制时使用BYPASSRLS绕过行级安全策略谨慎授予CONNECTION LIMIT限制并发连接数业务账号常用可防连接风暴VALID UNTIL密码有效期临时账号必备INHERIT / NOINHERIT是否继承成员角色的权限默认 INHERIT一般不用改举个例子创建一个有效期到今年年底、并发连接上限 50 的临时分析账号CREATE ROLE analyst_bob WITH LOGIN PASSWORD xxx CONNECTION LIMIT 50 VALID UNTIL 2025-12-31;这里有两个细节值得注意。第一VALID UNTIL到期后账号不是被删除而是无法登录数据都还在适合做短期外包或临时合作场景。第二CONNECTION LIMIT限制的是这个角色同时建立的连接数不是所有用户加起来的总连接数理解这一点就不会把参数设得太激进而影响正常业务。2.3 修改角色ALTER ROLE 的典型场景账号建好之后免不了要调整。最常见的几个操作-- 修改密码 ALTER ROLE app_rw WITH PASSWORD new_password; -- 临时禁用登录保留账号和数据 ALTER ROLE app_rw WITH NOLOGIN; -- 重新启用登录 ALTER ROLE app_rw WITH LOGIN; -- 修改连接数上限 ALTER ROLE app_rw WITH CONNECTION LIMIT 100;我的经验是遇到某个账号被怀疑泄露或需要暂停使用的情况先不要急着 DROP改为NOLOGIN是更稳妥的第一步。原因有两点DRO P 之后如果发现误判重建账号还要重新配权限而NOLOGIN撤销走 GRANT 即可影响面小得多。还有一类需求是修改角色在某个数据库里的默认配置比如要限制某个角色只在指定库里生效ALTER ROLE app_rw IN DATABASE appdb SET statement_timeout 30s;这样 app_rw 在其他数据库里不受影响只在 appdb 里执行超时 30 秒。这对写业务代码的同学特别有用因为可以在数据库层面做一道防线防止慢查询拖垮实例。2.4 删除角色依赖关系怎么处理DROP ROLE 报错是我见过的新手高频问题。最常见报错是ERROR: role app_rw cannot be dropped because some objects depend on it这个报错翻译成人话是这个账号名下还持有表、视图、序列等对象或者在某些对象的 owner 字段里。直接删是删不掉的得先把这些对象转给别人-- 把旧账号拥有的所有对象重新指派给另一个角色 REASSIGN OWNED BY app_rw TO app_owner; -- 删除旧账号拥有的、且不属于任何人的残留对象 DROP OWNED BY app_rw; -- 最后删除角色 DROP ROLE app_rw;REASSIGN OWNED BY会自动处理该角色在数据库中拥有的所有对象包括表、索引、视图、序列、函数、schema 等等。DROP OWNED BY会删除该角色拥有但尚未转移的对象。这两条命令执行时一定要确认目标角色选对了尤其DROP OWNED BY是删除对象而不是转移误操作后果很严重。我在实际运维里见过最危险的误操作就是有人为了删一个账号先把账号提升成超级用户然后强行 DROP。这种操作一旦出问题牵连的权限关系非常难恢复。正确的顺序永远是先转移所有权再清理最后删角色。3. 对象级授权语法详解GRANT / REVOKE 全参数解析账号建好之后真正的重头戏是对象级授权。这一层最灵活也最容易出错。3.1 对象权限类型一览PostgreSQL 里不同对象类型有不同的权限集合我用表格整理一下对象类型可授权权限数据库CREATE, CONNECT, TEMPORARYSchemaCREATE, USAGE表 / 视图 / 物化视图SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER, MAINTAIN序列USAGE, SELECT, UPDATE函数 / 过程EXECUTE类型USAGE表空间CREATE这里要解释一个容易混淆的点TRUNCATE和DELETE是两回事。DELETE 只删行数据TRUNCATE 是清空表并重置存储。如果一个账号只需要能删数据不给TRUNCATE是更安全的默认选择。再看REFERENCES权限它允许用户创建外键引用该表。平时业务账号可能不需要但如果有报表团队要把不同表关联起来做分析没有 REFERENCES 权限建外键或者 JOIN 某些场景会受限。这个权限经常被遗漏等别人来问为什么我建不了外键时才想起来。至于MAINTAIN这是 PostgreSQL 16 新增的权限专门用来解决非表 owner 想执行 VACUUM / ANALYZE 却能不开超级用户的问题。后面专门有一节单独讲这里先记住它属于对象级权限。3.2 GRANT 授权语法与常见场景授权语法可以总结为GRANT 权限列表 ON 对象类型 对象名 TO 被授权者 [WITH GRANT OPTION];一个典型只读账号授权需要同时处理数据库、Schema、表三层-- 允许连接数据库 GRANT CONNECT ON DATABASE appdb TO app_ro; -- 允许使用 schema GRANT USAGE ON SCHEMA public TO app_ro; -- 允许读取所有表数据 GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_ro;注意第二行USAGE ON SCHEMA它不等于能读表只表示允许进入这个 schema 并使用其中的对象。没有这一步后面 SELECT 授权做得再全也会报权限错误。这个分层设计不是多余的它允许你创建一个看得见门但进不去屋的账号对安全隔离很有用。如果你希望一次性把某个 schema 里所有表的所有权限都交给一个账号GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO app_rw;也可以针对特定表单独授权GRANT SELECT, INSERT, UPDATE, DELETE ON public.orders TO app_rw;还有一个容易被忽略但其实很重要的对象是序列。业务表经常有自增主键如果只给表授予INSERT权限却没有给序列授予USAGE权限插入时会报 permission denied for sequence。完整的读写账号授权必须把序列也覆盖进去GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO app_rw;3.3 WITH GRANT OPTION 和 REVOKE 的回收行为WITH GRANT OPTION表示被授权者可以把权限转授给其他人。这个选项的核心风险在于回收时需要级联因为权限链条已经往外延伸了。先看一下 REVOKE 的两种写法-- 普通回收只回收 alice 自己的权限 REVOKE SELECT ON public.orders FROM alice; -- 回收转授权能力alice 不能再给别人授权但它自己已有的权限还在 REVOKE GRANT OPTION FOR SELECT ON public.orders FROM alice; -- 级联回收回收权限同时把 alice 转授权产生的所有下游权限一并回收 REVOKE SELECT ON public.orders FROM alice CASCADE;我在生产环境处理过一次权限事故就是某位同事给一个外包账号加上了WITH GRANT OPTION外包账号又把它复制给了好几个服务账号。最后排查时不得不一路CASCADE回收虽然解决问题了但整个过程胆战心惊因为中间有一层关系没梳理清楚就可能误伤正常业务。所以我的建议很简单默认不要用 WITH GRANT OPTION需要让某个人帮忙管理权限的场景优先选择把他加进一个管理组角色而不是把转授权交给他个人。3.4 ALTER DEFAULT PRIVILEGES一次性解决新表没权限问题手动 GRANT 最大的痛点在于只对当前已存在的对象有效。今天授权了 100 张表明天开发新建一张表新账号还是没有权限。如果每次建表都手工补 GRANT权限管理就会变成一场永无休止的追赶游戏。ALTER DEFAULT PRIVILEGES就是为这个问题设计的。它的作用是定义未来由某个角色创建的对象默认授权给谁ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_rw; ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA public GRANT USAGE, SELECT ON SEQUENCES TO app_rw;这两行命令的意思是当app_owner这个角色在 public schema 里新建表时这些新表自动授予 app_rw 读写权限新建序列时自动授予 app_rw 使用权限。注意FOR ROLE app_owner是关键它限定了谁的建表行为会触发默认授权如果建表的人不是 app_owner这个默认权限不生效。在实际项目里我会要求应用相关的表统一由某个建表角色创建比如app_owner这样配合ALTER DEFAULT PRIVILEGES整个对象生命周期内的权限都能自动覆盖。已经存在的表再用GRANT ON ALL TABLES批量补齐一次双管齐下。这里还有个容易踩的细节默认权限只对新建对象有效不会回头修改已有对象。所以新上线一个项目时正确的顺序是先手动批量授权已有对象再设置默认权限并让后续对象都使用指定角色创建。4. 更高阶的权限控制手段预定义角色、成员关系与行级安全如果只是单人小项目前面三节的内容已经够用了。但生产环境往往有多角色分权的问题这就要用到 PostgreSQL 提供的组角色和预定义角色体系。4.1 预定义角色官方帮你审计好的常用权限包PostgreSQL 内置了一批预定义角色本质上是官方定义好的权限组直接 GRANT 给某个账号即可预定义角色用途pg_read_all_data读取所有数据库对象相当于全局只读pg_write_all_data写入所有数据库对象相当于全局读写pg_maintain对所有对象执行 VACUUM、ANALYZE、CLUSTER、REINDEX 等维护操作pg_monitor读取监控相关视图和函数pg_signal_backend取消或终止其他用户的后端进程pg_checkpoint执行 CHECKPOINTpg_use_reserved_connections使用预留连接槽位pg_create_subscription创建逻辑复制订阅pg_execute_server_program执行服务端程序用于 COPY 等场景举例来说需要一个全局只读的监控账号CREATE ROLE monitor_user WITH LOGIN PASSWORD monitor_pass; GRANT pg_monitor TO monitor_user; GRANT pg_read_all_data TO monitor_user;这样 monitor_user 既能看监控视图也能读所有业务表比手动给几百张表逐个授权要省太多事。我建议不要自行模拟这些权限直接使用官方预定义角色因为 PG 后续版本会跟随系统目录变化维护这些角色的定义。4.2 成员关系与 INHERIT组角色的行为边界当你执行GRANT group_role TO user_role时user_role 就成为了 group_role 的成员。成员继承权限的行为受 INHERIT 属性控制。默认情况下角色 INHERIT成员角色自动获得组角色的对象权限不需要显式切换。比如CREATE ROLE app_ro_group; GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_ro_group; CREATE ROLE alice LOGIN PASSWORD xxx; GRANT app_ro_group TO alice;默认情况下 alice 登录后直接可以查询 public schema 的所有表因为在权限检查时PostgreSQL 会沿着角色成员链一路向上找权限。但有一个例外要特别记住INHERIT 只对对象权限生效对角色属性LOGIN、SUPERUSER、CREATEDB 等不生效。也就是说即使某个角色是超级用户的成员它也不会因此自动成为超级用户需要切换身份或者显式设置 SET ROLE 才能使用超级用户属性。这个设计其实是为了防止权限链无意间放大理解之后就不会觉得它反直觉了。4.3 SET ROLE临时切换身份有时候你需要以某个组角色的身份执行操作而不是自己的身份。比如一个 DBA 平时用低权限账号登录做维护时临时切换成维护角色SET ROLE pg_maintain; -- 执行 ANALYZE 等操作 ANALYZE public.orders; RESET ROLE;SET ROLE和SET SESSION AUTHORIZATION的区别需要理清前者切换的是当前会话中的角色身份后者切换的是会话所属的登录用户身份。日常运维中基本不用后者前者足够。有一个小坑RESET ROLE 之后会回到登录角色的默认权限但如果你开了多个嵌套的 SET ROLE需要一层层 RESET。生产环境里我发现很多同学在脚本里写了 SET ROLE但忘写 RESET ROLE于是脚本后续所有操作都带着高权限身份执行这个隐患在审计时会被拎出来重点查。4.4 行级安全RLS让同一张表对不同用户显示不同行对象级权限控制的是能不能操作这张表行级安全Row-Level Security控制的是能操作这张表的哪些行。两者互补在实际的多租户场景里非常有价值。启用 RLS 的步骤是-- 1. 启用表的行级安全 ALTER TABLE public.orders ENABLE ROW LEVEL SECURITY; -- 2. 创建一条策略比如只允许用户看到属于自己组织的数据 CREATE POLICY tenant_isolation ON public.orders USING (org_id current_setting(app.org_id)::int);这条策略的含义是当用户查询 orders 表时PostgreSQL 会自动追加一个条件org_id current_setting(app.org_id)。如果你在同一个表里存了 A 和 B 两个租户的数据A 租户的连接即使执行SELECT * FROM orders也只能看到自己的行。启用 RLS 后默认行为是拒绝也就是说如果没有匹配的策略普通用户看不到任何行。表 owner 和超级用户默认不受 RLS 限制除非你显式执行FORCE ROW LEVEL SECURITY。业务账号如果不想被 RLS 影响可以给角色加BYPASSRLS属性但这等于放弃了行级安全防线需要严格评估。RLS 是把双刃剑它极大地增强了多租户隔离能力但也会让 SQL 执行计划变得更复杂而且策略本身如果写得不对可能连 owner 都查不到数据。我建议在开发阶段就启用并做好充分测试不要等生产数据进去之后再“补”策略。5. 实战从开发库到生产库一套完整授权方案设计理论讲了那么多还是落到一个实际场景里看看完整做法。假设现在要为一个中型 Web 应用设计数据库权限业务库叫 appdbschema 是 app表结构由团队维护。5.1 场景与角色拆分我们需要三类角色角色用途权限范围app_owner建表、改表结构DDL 操作schema 和对象的 ownerapp_rw应用服务运行账号DML 操作表的增删改查、序列使用app_ro报表、临时查询、数据导出表只读再加上一个管理员账号 admin_dba用于日常 DBA 操作拥有超级用户权限。这样设计的核心思想是应用连接时用 app_rw 或 app_ro不要用拥有对象的账号直接跑 DML避免应用账号误操作 DDL。5.2 落地步骤第一步创建数据库和 schema并指定 ownerCREATE DATABASE appdb OWNER app_owner; \connect appdb CREATE SCHEMA app AUTHORIZATION app_owner;第二步创建应用账号CREATE ROLE app_rw WITH LOGIN PASSWORD rw_pass; CREATE ROLE app_ro WITH LOGIN PASSWORD ro_pass CONNECTION LIMIT 20;第三步授予数据库连接和 schema 使用权限GRANT CONNECT ON DATABASE appdb TO app_rw, app_ro; GRANT USAGE ON SCHEMA app TO app_rw, app_ro;第四步配置默认权限让 app_owner 未来新建的任何表自动授权ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_rw; ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app GRANT USAGE, SELECT ON SEQUENCES TO app_rw; ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app GRANT SELECT ON TABLES TO app_ro; ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app GRANT SELECT ON SEQUENCES TO app_ro;第五步如果 schema 里已经有一些表比如从旧库迁过来需要手动批量补一次权限GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA app TO app_rw; GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA app TO app_rw; GRANT SELECT ON ALL TABLES IN SCHEMA app TO app_ro; GRANT SELECT ON ALL SEQUENCES IN SCHEMA app TO app_ro;到这里app_rw 登录后可以直接读写应用表app_ro 登录后可以查询、导出数据两者都没有 DDL 权限也不会误删表结构。5.3 权限验收与检查授权完成后不能只看好像能用了要做一次系统性的检查。我常用的检查 SQL 是以 grantee 维度查看表权限SELECT grantee, privilege_type, table_name FROM information_schema.role_table_grants WHERE table_schema app ORDER BY grantee, table_name, privilege_type;另一个方式是从系统目录看 ACL能看到每个对象的授权全貌SELECT n.nspname AS schema, c.relname AS table, pg_get_userbyid(c.relowner) AS owner, acl.privileges FROM pg_class c JOIN pg_namespace n ON n.oid c.relnamespace LEFT JOIN LATERAL aclexplode(c.relacl) AS acl ON TRUE WHERE c.relkind r AND n.nspname app ORDER BY n.nspname, c.relname;aclexplode是理解 PostgreSQL ACL 的利器它可以把表上的 ACL 数组展开成一行行权限记录方便导出审计。建议把这两条 SQL 保存成常用查询脚本每次给新环境配置完权限后跑一遍。5.4 方案延伸环境隔离开发库、测试库、生产库的权限应该分开设计不要在三个环境共用一套密码。我见过不少团队开发环境直接用超级用户跑业务等到了生产环境才想起来收敛权限结果应用上线第一天就因为权限不足报错手忙脚乱补授权。正确的节奏是开发环境可以宽松但生产库从第一张表开始就执行 app_rw / app_ro 的最小权限原则。权限这场仗应该在生产环境之前就打赢而不是在生产环境边救火边总结。6. 升级到 PostgreSQL 16权限这块要注意什么PG16 在权限管理上做了几个比较重要的调整从旧版本升级后如果不了解这些变化很容易踩雷。6.1 新增 MAINTAIN 权限PG16 之前要对一张不是自己拥有的表执行VACUUM或ANALYZE通常需要超级用户。这在分权管理的环境里很麻烦业务表的 owner 可能是一个建表账号但日常维护人员并不需要拥有表的所有权限只想做统计分析和优化。PG16 新增了MAINTAIN权限专门解决这类需求。拥有某张表的 MAINTAIN 权限后就可以对该表执行 VACUUM、ANALYZE、CLUSTER、REINDEX 等维护操作不需要成为表 owner也不需要超级用户。授权方式和其他对象权限完全一样GRANT MAINTAIN ON TABLE public.orders TO maintainer_role;也可以批量授权GRANT MAINTAIN ON ALL TABLES IN SCHEMA app TO maintainer_role;这个权限非常适合运维团队和数据分析团队。他们需要做定期的ANALYZE来生成统计信息但不需要也不应该有 DDL 权限。过去很多团队只能给这类账号开超级用户风险很大有了 MAINTAIN 之后授权粒度精细了很多。6.2 新增预定义角色 pg_maintain与 MAINTAIN 权限配套PG16 还新增了pg_maintain预定义角色。授予这个角色的账号可以对数据库内的所有对象执行维护操作而无需拥有这些对象GRANT pg_maintain TO maintainer_role;这里要区分的场景是MAINTAIN是对象级权限适合精确指定某几张表pg_maintain是全局角色适合这个人要做全区维护的场景。两者可以叠加使用但实际设计权限方案时我会优先考虑 MAINTIAIN 精确授权只有维护人员数量多、且维护范围覆盖全库时才考虑直接给 pg_maintain。6.3 从 PG15 / PG14 升级时容易踩的权限问题public schema 的默认 CREATE 权限变化。PG15 之后public schema 不再默认对 public 角色授予 CREATE 权限。这意味着从 PG14 升级到 PG15 或 PG16 后普通用户在同一数据库的 public schema 里建表的操作会失败。如果你的应用确实需要在 public schema 里动态建表需要显式授予GRANT CREATE ON SCHEMA public TO app_rw;但更建议的做法是使用独立 schema而不是继续在 public 里建业务表。public schema 的定位应该是默认放系统信息的业务表放独立 schema 会更安全。预定义角色的成员关系不会自动迁移。升级后检查一遍\du确认 pg_read_all_data、pg_monitor 等角色的授权是否还在。有些安全加固类工具在旧版本里直接改系统表添加角色成员关系升级后可能失效。密码认证方式的兼容。PG16 已经默认使用 SCRAM-SHA-256 密码加密如果旧库里有使用 md5 认证的账号升级后连接可能失败需要在 pg_hba.conf 和密码格式上做好同步。这一点虽然不是纯权限问题但影响登录行为排查时常常容易往权限方向误判。6.4 升级后的权限审计清单作为运维习惯升级完成后我会按这个清单快速过一遍用\du查看所有角色及属性确认超级用户列表没有异常膨胀。用\l查看数据库 owner 和权限确认没有 plan 以外的默认 public 权限开放。用\dn查看 schema 权限尤其确认 schema 的 CREATE 权限是否符合预期。抽查几张核心表确认业务账号的 SELECT / INSERT / UPDATE / DELETE 权限正确。确认 pg_maintain、MAINTAIN 等新权限没有被错误授予给不必要的账号。这套检查我一般会在升级演练环境的测试阶段做一次生产切换后立刻再做一次前后对比能快速发现权限配置漂移。7. 权限问题排查思路与运维心得最后一部分聊一聊真正遇到权限问题时应该怎么排查。这部分内容很实战建议保存下来遇到问题时候再翻。7.1 常见权限报错与含义报错信息常见原因permission denied for schema publicSchema 层 USAGE 权限缺失permission denied for table orders表级 SELECT / INSERT 等权限缺失permission denied for sequence orders_id_seq序列 USAGE 权限缺失permission denied for database appdb数据库 CONNECT 权限缺失must be owner of table orders当前角色不是 owner且没有 MAINTAIN 权限role does not exist角色名写错了或者还没有创建排查思路可以总结成一条链先确认能不能连上库再看能不能进 schema再看能不能操作表一层一层往里走。很多人习惯直接去查表权限查了半天没发现问题最后发现是数据库连接权限没给白白折腾。7.2 快速定位一次权限问题的复盘路径假设你收到反馈账号 bob 查不了 public.orders 表。我会按这个顺序快速定位第一步确认 bob 是否存在及是否能登录SELECT rolname, rolcanlogin, rolsuper FROM pg_roles WHERE rolname bob;第二步确认 bob 对 appdb 的连接权限SELECT has_database_privilege(bob, appdb, CONNECT);第三步确认 bob 对 public schema 的权限SELECT has_schema_privilege(bob, public, USAGE);第四步确认 bob 对 orders 表的权限SELECT has_table_privilege(bob, public.orders, SELECT); SELECT has_table_privilege(bob, public.orders, INSERT);每一步返回true或false很快就能定位是哪一层权限缺失。这比翻\dp输出直观得多尤其是权限关系复杂、有多层组角色嵌套时直接查询某个角色最终是否拥有某项权限才是真正有效的办法。7.3 长期权限运维的几个习惯第一不要随手给业务账号开超级用户。超级用户会绕过所有权限检查会掩盖掉所有权限设计上的漏洞。业务代码里有不当操作只有把它们暴露在最小权限环境下才能尽早暴露问题。第二角色的命名和用途要有记录。我见过一个库里有 20 多个角色没人说得清哪个角色是干什么用的。建议在备注里写明用途比如创建角色时加上 COMMENTCOMMENT ON ROLE app_rw IS appdb 应用读写账号仅用于Web服务禁止用于日常运维;第三定期做权限审计。至少每季度导出一次所有角色和各 schema 的 ACL交给负责人确认。权限这个东西时间一长就会因为各种临时授权逐步“膨胀”等出事的时候再去追溯成本远高于日常定期检查。第四利用ALTER DEFAULT PRIVILEGES作为权限管理的主路径而不是事后补 GRANT。每次新项目上线我都会先设计好默认权限再让业务账号接触数据库。这能避免绝大多数新表没权限的凌晨告警。第五不要把权限都放在一个角色里。哪怕项目规模不大也尽量保持owner 角色 读写角色 只读角色的结构。这个成本很低但对后续的权限收敛和安全审计帮助极大。我在实际维护中最大的体会是权限管理做得好不好往往不是看某一条授权语句写得有多完美而是看整个体系是否可预期。所谓可预期就是你不用翻半天日志也能说出某个角色在某些条件下能做什么、不能做什么。PostgreSQL 提供的能力足够支撑这个目标关键是把语法用对、把边界想清楚然后让规则长期稳定地执行下去。希望这篇把概念和实战串起来的内容能让你在搭权限体系的时候少走一些弯路。