From: o.tselebrovskiy@postgrespro.ru
To: pgsql-hackers@postgresql.org
Cc: s.shinderuk@postgrespro.ru
Subject: A bug with ExecCheckPermissions
Date: Wed, 08 Feb 2023 15:21:03 +0700
Message-ID: <3722b7a2cbe27a1796ee40824bd86dd1@postgrespro.ru> (raw)
Greetings, everyone!
While working on an extension my colleague and I have found an
interesting case;
When you try to execute next SQL statements on master branch of
PostgreSQL:
CREATE TABLE parted_fk_naming (
id bigint NOT NULL default 1,
id_abc bigint,
CONSTRAINT dummy_constr FOREIGN KEY (id_abc)
REFERENCES parted_fk_naming (id),
PRIMARY KEY (id)
)
PARTITION BY LIST (id);
CREATE TABLE parted_fk_naming_1 (
id bigint NOT NULL default 1,
id_abc bigint,
PRIMARY KEY (id),
CONSTRAINT dummy_constr CHECK (true)
);
ALTER TABLE parted_fk_naming ATTACH PARTITION parted_fk_naming_1 FOR
VALUES IN ('1');
seemingly nothing suspicious happens.
But if you debug function ExecCheckPermissions and look into what is
passed to function (contents of rangeTable and rteperminfos to be
exact),
you'll see some strange behaviour:
(
{RANGETBLENTRY
:alias <>
:eref <>
:rtekind 0
:relid 16395
:relkind r
:rellockmode 1
:tablesample <>
:perminfoindex 0
:lateral false
:inh false
:inFromCl false
:securityQuals <>
}
{RANGETBLENTRY
:alias <>
:eref <>
:rtekind 0
:relid 16384
:relkind p
:rellockmode 1
:tablesample <>
:perminfoindex 0
:lateral false
:inh false
:inFromCl false
:securityQuals <>
}
)
(
{RTEPERMISSIONINFO
:relid 16395
:inh false
:requiredPerms 2
:checkAsUser 0
:selectedCols (b 9)
:insertedCols (b)
:updatedCols (b)
}
{RTEPERMISSIONINFO
:relid 16384
:inh false
:requiredPerms 2
:checkAsUser 0
:selectedCols (b 8)
:insertedCols (b)
:updatedCols (b)
}
)
Both of RangeTableEntries have a perminfoindex of 0 and simultaneously
have a RTEPERMISSIONINFO entry for them!
Right now this behaviour isn't affecting anything, but in future should
someone want to use ExecutorCheckPerms_hook from
/src/backend/executor/execMain.c, its input parameters
won't correspond to each other since members of rangeTable will have
incorrect perminfoindex.
To fix this, we're setting fk's index to 1 and pk's index to 2 in
/src/backend/utils/adt/ri_triggers.c so that list being passed to
ExecCheckPermissions and its hook
has indexes for corresponding rteperminfos entries. 1 and 2 are chosen
because perminfoindex is 1-based and fk is passed to list_make2 first;
We are eager to hear some thoughts from the community!
Regards,
Oleg Tselebrovskii
Attachments:missing-perminfoindex.diff (text/x-diff, 893B) downloaddiff --git a/src/backend/utils/adt/ri_triggers.c b/src/backend/utils/adt/ri_triggers.cindex 29f29d664b6..7666886742a 100644--- a/src/backend/utils/adt/ri_triggers.c+++ b/src/backend/utils/adt/ri_triggers.c@@ -1399,6 +1399,7 @@ RI_Initial_Check(Trigger *trigger, Relation fk_rel, Relation pk_rel)
pkrte->relid = RelationGetRelid(pk_rel);
pkrte->relkind = pk_rel->rd_rel->relkind;
pkrte->rellockmode = AccessShareLock;
+ pkrte->perminfoindex = 2;
pk_perminfo = makeNode(RTEPermissionInfo);
pk_perminfo->relid = RelationGetRelid(pk_rel);
@@ -1409,6 +1410,7 @@ RI_Initial_Check(Trigger *trigger, Relation fk_rel, Relation pk_rel)
fkrte->relid = RelationGetRelid(fk_rel);
fkrte->relkind = fk_rel->rd_rel->relkind;
fkrte->rellockmode = AccessShareLock;
+ fkrte->perminfoindex = 1;
fk_perminfo = makeNode(RTEPermissionInfo);
fk_perminfo->relid = RelationGetRelid(fk_rel);
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: o.tselebrovskiy@postgrespro.ru, s.shinderuk@postgrespro.ru
Subject: Re: A bug with ExecCheckPermissions
In-Reply-To: <3722b7a2cbe27a1796ee40824bd86dd1@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox