触发器只能拦截dml（insert/update/delete/truncate）操作，无法阻止grant/revoke、create function、set role等ddl或会话级权限变更；它可校验租户/角色一致性并拒绝非法写入，但防提权需依赖rbac+rls+最小权限设计。
触发器本身不能防止提权——它不干预权限授予过程，也不阻止用户执行高危语句（比如 CREATE FUNCTION 或 SET ROLE）。但你可以用触发器在关键操作发生时主动拦截、记录或拒绝，从而限制已获特殊权限的用户滥用这些权限。
触发器能拦什么？不能拦什么？
触发器只对 DML（INSERT/UPDATE/DELETE）和 TRUNCATE 生效，且仅作用于你显式绑定的表。它拦不住：
-
GRANT/REVOKE语句（DDL，触发器不监听） -
CREATE FUNCTION或CREATE EXTENSION（除非你用事件触发器，但事件触发器不能RAISE EXCEPTION中断 DDL） -
SET SESSION AUTHORIZATION或SET ROLE（会话级权限切换，触发器无感知） - 对系统表（如
pg_authid、pg_shdepend）的查询或修改（RLS 不生效，触发器也不绑定）
但它能拦住：用户用已有权限往敏感表写入恶意数据、篡改租户标识、绕过业务规则插入越权记录等行为。
BEFORE INSERT/UPDATE 拦截非法 tenant_id 或 role_id
当用户拥有 INSERT 权限却试图伪造归属关系时，这是最常见提权入口。例如攻击者向 users 表插入 role_id = 'admin'，或把 tenant_id 改成其他租户值。
做法是写一个 BEFORE 行级触发器，在写入前校验上下文一致性：
CREATE OR REPLACE FUNCTION enforce_tenant_role_integrity()
RETURNS TRIGGER AS $$
BEGIN
IF current_setting('app.tenant_id', true) IS NULL THEN
RAISE EXCEPTION 'Missing app.tenant_id session variable';
END IF;
<p>IF NEW.tenant_id != current_setting('app.tenant_id')::UUID THEN
RAISE EXCEPTION 'tenant_id mismatch: % ≠ %',
NEW.tenant_id, current_setting('app.tenant_id');
END IF;</p><p>IF TG_OP = 'INSERT' AND NEW.role_id = 'admin' THEN
RAISE EXCEPTION 'Direct admin role insertion forbidden';
END IF;</p><p>RETURN NEW;
END;
$$ LANGUAGE plpgsql;</p>
然后绑定到目标表：
CREATE TRIGGER check_tenant_role BEFORE INSERT OR UPDATE ON users FOR EACH ROW EXECUTE FUNCTION enforce_tenant_role_integrity();
注意点：
- 必须配合应用层严格执行
SET app.tenant_id = 'xxx'，否则触发器失效 - 不要用
current_user做权限判断——它可被SET ROLE切换，不可信 - 若允许部分管理员跨租户操作，需额外校验角色能力，而非硬编码
'admin'
用触发器审计高危操作，而非阻止
有些操作你无法或不该直接阻断（比如 UPDATE 自己的密码），但可以强制留痕并告警：
例如监控对 pg_authid 的间接影响（通过修改 users 表触发角色变更）：
CREATE OR REPLACE FUNCTION log_privileged_update()
RETURNS TRIGGER AS $$
BEGIN
IF OLD.role_id != NEW.role_id AND NEW.role_id IN ('superuser', 'admin') THEN
INSERT INTO audit_log (table_name, operation, old_data, new_data, changed_by)
VALUES ('users', 'UPDATE', to_jsonb(OLD), to_jsonb(NEW), current_user);
<pre class="brush:php;toolbar:false;">-- 可选：发通知或调用外部 webhook（需 <code>plpythonu</code> 或外部队列）END IF; RETURN NEW; END; $$ LANGUAGE plpgsql;
这类触发器的价值在于事后追溯——一旦发现提权，你能立刻定位到哪条记录被改、谁改的、改前什么样。
关键约束：
-
audit_log表必须设为只允许 INSERT（禁用 UPDATE/DELETE），且由独立角色管理 - 触发函数里避免调用非
LEAKPROOF函数，防止侧信道泄露（比如用pg_sleep()推断条件真假） - 别把敏感字段（如密码哈希）全量写进
new_data，应脱敏或只记变更字段名
真正防提权靠的是权限模型设计，不是触发器
触发器只是最后一道“业务逻辑闸门”。真正防住提权的关键动作是：
- 撤销
PUBLIC在publicschema 上的CREATE权限：REVOKE CREATE ON SCHEMA public FROM PUBLIC; - 所有业务表放在独立 schema（如
app），只给最小角色授权 - 启用 RLS 并强制开启
FORCE ROW LEVEL SECURITY，避免超级用户绕过 - 禁用或严格审计
CREATE FUNCTION权限——90% 的 PostgreSQL 提权始于自定义函数
触发器补不了权限模型的窟窿。它只在你已经划好边界的前提下，帮你守住那条线不被悄悄跨过去。
