From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
Cc: | Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
Date: | 2024-04-28 11:36:51 |
Message-ID: | CAPpHfdsC3Ci5ece78c9+sPW-8+Bb0V=FzMpgxb7QxcBWHVPdCA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Apr 28, 2024 at 2:00 PM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> 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?
Alexander, thank you for discovering this. I believe that the one who
merges partitions should have permissions for all the partitions
merged. I'll recheck this and provide the patch.
------
Regards,
Alexander Korotkov
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2024-04-28 13:18:42 | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
Previous Message | Tatsuo Ishii | 2024-04-28 11:28:26 | Re: Row pattern recognition |