A bug with ExecCheckPermissions

[o . tselebrovskiy]

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 Tselebrovskiidiff --git a/src/backend/utils/adt/ri_triggers.c b/src/backend/utils/adt/ri_triggers.c
index 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);