如何在PostgreSQL 16中通过行级安全策略限制特定用户的DELETE权限？-SQL-PHP中文网

create policy 时必须显式指定 for delete，postgresql 不会为未声明的操作自动应用策略；即使已定义 select 或 update 策略，delete 仍默认允许（仅受表级权限约束），需单独创建 for delete 策略并用 using 表达式限定可删行，不支持 with check，且强制行级安全（force row level security）才使所有者受限制。

如何在postgresql 16中通过行级安全策略限制特定用户的delete权限？

CREATE POLICY 时必须显式指定 FOR DELETE

PostgreSQL 不会自动为未声明的操作类型应用策略。即使你已经为 SELECT 或 UPDATE 创建了策略，DELETE 仍默认允许（只要用户有表级 DELETE 权限）。要限制 DELETE，必须单独创建一条 FOR DELETE 策略。

常见错误现象：用户能正常 SELECT 自己的数据，也能成功执行 DELETE FROM table WHERE id = 123，但实际删掉了别人的数据——因为根本没定义 DELETE 策略。

实操建议：

Pixie.haus

一款面向像素艺术创作的AI图像生成平台，帮助用户快速制作像素风格图片和适合游戏等项目使用的视觉素材。

下载

策略必须用 FOR DELETE 明确声明，不能省略或混在 FOR ALL 里依赖隐式覆盖
USING 表达式决定“哪些行允许被删除”，它只检查现有行是否匹配条件，不验证新值（DELETE 没有新值）
例如限制用户只能删自己插入的记录：CREATE POLICY delete_own_data ON sensitive_data FOR DELETE USING (user_id = current_user);
若需更严格控制（如禁止删除已归档数据），可在 USING 中加入复合条件：USING (user_id = current_user AND status != 'archived')

DELETE 策略不支持 WITH CHECK

WITH CHECK 只对涉及“写入新状态”的操作有效，比如 INSERT 和 UPDATE。而 DELETE 是移除整行，没有“新行值”可校验，因此语法上不允许 WITH CHECK 子句。

这意味着你无法用 RLS 阻止“因关联更新导致的间接删除”，比如触发器或 ON DELETE CASCADE。RLS 的 DELETE 限制仅作用于直接 DELETE 语句。

实操建议：

不要尝试写 CREATE POLICY ... FOR DELETE WITH CHECK (...)，会报错 syntax error at or near "WITH"
如果业务要求“软删除”或状态驱动删除，应把逻辑放在 USING 条件中，例如：USING (user_id = current_user AND deleted_at IS NULL)
级联删除不受 RLS 约束，需靠外键约束或应用层控制

FORCE ROW LEVEL SECURITY 影响 DELETE 行为

默认情况下，表所有者（owner）和超级用户（superuser）执行 DELETE 时会绕过 RLS 策略。如果你希望连所有者也受限制，必须启用强制模式：

ALTER TABLE sensitive_data FORCE ROW LEVEL SECURITY;

这个命令影响所有操作类型，包括 DELETE。一旦启用，所有角色（含所有者）都必须满足策略条件才能删除行。

容易踩的坑：

误以为 ENABLE ROW LEVEL SECURITY 就够了——其实它只启用策略机制，不改变所有者豁免规则
在生产环境执行 FORCE 前未测试运维账号行为，导致 DBA 无法紧急清理脏数据
FORCE 是表级开关，不能按用户或会话动态关闭；调试时需临时 DISABLE 再恢复

测试 DELETE 策略是否生效的关键步骤

光看 CREATE POLICY 成功不等于策略起作用。必须用目标用户身份连接并实测，否则容易漏掉权限或上下文问题。

实操建议：

用 psql -U target_user -d dbname 切换到被限制用户，再执行 DELETE，观察是否报错 no rows to delete 或静默失败（取决于策略条件是否匹配）
确认该用户确实有表级 DELETE 权限：GRANT DELETE ON sensitive_data TO target_user;，否则 RLS 根本不会触发（先卡在权限层）
检查策略是否被禁用：SELECT polname, polcmd, polqual, polwithcheck FROM pg_policy WHERE polrelid = 'sensitive_data'::regclass;，确认 polcmd = 'D' 且 polqual 非空
注意 current_user 和 session_user 差异：若使用连接池或代理，实际会话用户可能不是预期角色，建议统一用 current_user 并确保登录角色与策略逻辑一致