Hello,
28.04.2024 03:59, Alexander Korotkov wrote:
> The revised patchset is attached. I'm going to push it if there are
> no objections.
I have one additional question regarding security, if you don't mind:
What permissions should a user have to perform split/merge?
When we deal with mixed ownership, say, bob is an owner of a
partitioned table, but not an owner of a partition, should we
allow him to perform merge with that partition?
Consider the following script:
CREATE ROLE alice;
GRANT CREATE ON SCHEMA public TO alice;
SET SESSION AUTHORIZATION alice;
CREATE TABLE t (i int PRIMARY KEY, t text, u text) PARTITION BY RANGE (i);
CREATE TABLE tp_00 PARTITION OF t FOR VALUES FROM (0) TO (10);
CREATE TABLE tp_10 PARTITION OF t FOR VALUES FROM (10) TO (20);
CREATE POLICY p1 ON tp_00 USING (u = current_user);
ALTER TABLE tp_00 ENABLE ROW LEVEL SECURITY;
INSERT INTO t(i, t, u) VALUES (0, 'info for bob', 'bob');
INSERT INTO t(i, t, u) VALUES (1, 'info for alice', 'alice');
RESET SESSION AUTHORIZATION;
CREATE ROLE bob;
GRANT CREATE ON SCHEMA public TO bob;
ALTER TABLE t OWNER TO bob;
GRANT SELECT ON TABLE tp_00 TO bob;
SET SESSION AUTHORIZATION bob;
SELECT * FROM tp_00;
--- here bob can see his info only
\d
Schema | Name | Type | Owner
--------+-------+-------------------+-------
public | t | partitioned table | bob
public | tp_00 | table | alice
public | tp_10 | table | alice
-- but then bob can do:
ALTER TABLE t MERGE PARTITIONS (tp_00, tp_10) INTO tp_00;
-- (yes, he also can detach the partition tp_00, but then he couldn't
-- re-attach nor read it)
\d
Schema | Name | Type | Owner
--------+-------+-------------------+-------
public | t | partitioned table | bob
public | tp_00 | table | bob
Thus bob effectively have captured the partition with the data.
What do you think, does this create a new security risk?
Best regards,
Alexander