PostgreSQL 又补齐一块内置角色的缺失权限拼图

本期播客

PostgreSQL 又补齐一块内置角色的缺失权限拼图

在数据库安全领域，“超级用户（Superuser）” 一直是一把让人又爱又恨的双刃剑。为了完成全库备份或数据迁移，运维人员往往不得不动用 postgres 超级账号。这就像是为了进屋拿件衣服，却被迫把整栋大楼的万能钥匙交给了一个外人。

2026年2月，PostgreSQL（以下简称 PG）社区合并了一项关键提交：正式允许内置角色 pg_read_all_data 和 pg_write_all_data 访问大对象（Large Objects, LO）。

这不只是一个小功能的修补，这是 PG 彻底走向“去超级用户化” 、完善最小权限原则（PoLP） 的最后几块拼图之一。

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=d98197602790e60ddb63e491cd9768ab9fc410ed

一、 痛点：被遗忘的“大对象”阴影

长期以来，PG 的内置角色 pg_read_all_data 被寄予厚望，旨在让非超级用户也能通过 pg_dump 完成全库导出。但在实操中，DBA 们经常撞墙：

• 现状： 即使你拥有 pg_read_all_data 权限，一旦数据库中存有 Large Objects（例如存储在 pg_largeobject 表中的图片、PDF 或超长文本），读取操作依然会报权限错误。
• 后果： 备份任务因权限不足而中断。为了让任务跑通，DBA 只能含泪给备份账号加上 SUPERUSER 属性。
• 安全隐患： 一旦这个备份账号泄露，黑客不仅能读数据，还能通过 COPY FROM PROGRAM 等手段直接提权控制操作系统。

这就是所谓的“合规性困境”：你想要安全，但系统功能的不完备逼着你走向不安全。

二、 技术剖析：大对象权限的“拨乱反正”

此次更新由 Google 的工程师和 PG 核心委员会成员共同推动，其核心逻辑非常直接：数据一致性。

1. 逻辑自洽的特权模型

从第一性原理来看，如果一个角色的名字叫“读取所有数据（read all data）”，那么逻辑上它就不应该漏掉大对象。

• 此前逻辑： 权限检查分散在普通表和大对象管理函数（如 lo_open）之间。
• 现状逻辑： 内核将 pg_read_all_data 和 pg_write_all_data 的特权范围扩展到了大对象操作函数。这意味着，当你被赋予这两个角色时，你真正拥有了横跨全库所有存储介质的通行证。

2. 彻底告别“伪非超”备份

这一变动最大的受益者是 pg_dump。从此，我们可以真正创建一个“只有读取权、没有破坏权” 的备份账号。这在多租户环境或云数据库（RDS）场景下，是安全架构的刚性需求。

三、 权威案例：为何“最小权限”是救命稻草？

1. 工业界的安全教训

权威数据： 根据 IBM 发布的《数据泄露成本报告》，配置错误和特权账号管理不当是导致数据泄露的头号杀手，平均每次泄露损失高达 400万美元。
案例： 某知名 SaaS 供应商曾因备份脚本中硬编码了超级用户密码，导致数据库被勒索软件利用该账号执行了系统级命令，全库数据被加密。如果当时使用的是受限的 pg_read_all_data，黑客即便拿到密码，也无法在宿主机执行任何命令。

2. 审计合规的刚需

在金融行业的 SOC2 或 等保 2.0 审计中，“生产环境严禁非必要超级用户”是一条铁律。PG 此次补齐权限拼图，让企业可以理直气壮地删掉那些“为了备份而存在”的超级账号。

四、 逻辑的崩塌：当“大对象”不再是大对象

前提假设： 我们假设“大对象（Large Objects）”依然是存储非结构化数据的主要方式。
条件崩塌： 随着 JSONB、TOAST 技术的成熟，以及对象存储（如 S3）的普及，现代应用直接在 PG 内部使用 Large Objects 的频率正在下降。

引申观点： 如果你的业务已经完全转用外部存储，这次更新对你的影响微乎其微。但对于那些承载了十几年历史数据的电信、医疗系统（如存储医学影像） 来说，这就是一次“史诗级”的运维解放。

结语

PostgreSQL 对安全性的追求从来不是激进的，而是那种“老派的严谨”。

补齐 pg_read_all_data 对大对象的访问权限，标志着 PG 的内置权限体系已经足够成熟，足以支撑起最苛刻的企业级安全模型。它再次向开发者传递了一个信号：在 PostgreSQL 面前，安全与便利不再是二选一的难题。

那么问题来了：既然拼图已经补齐，你还有什么理由在生产环境的备份脚本里，继续保留那个危险的 SUPERUSER 账号呢？