MIME-Version: 1.0
References: <e711faa8-826d-434d-b197-ab51da518fe7@postgrespro.ru>
 <f79fa76f-de07-b930-0bc7-359d6cbab159@gmail.com> <b156efc2-5e6d-4eae-8e60-2d483987b42c@postgrespro.ru>
 <CAPpHfdv-uR663BO6G2kRuLEQjob+UBHuD3iyXF+qGHXQFRN0-Q@mail.gmail.com>
 <56e0000c-6b39-44ce-90b4-d3c3062e408c@postgrespro.ru> <CAPpHfdvShLh5txtQdh6=ZMCnzGZHv8W+RHAe8pY94rfzghWTAg@mail.gmail.com>
 <5dee3937-8e9f-cca4-11fb-737709a92b37@gmail.com> <f8b5cbf5-965e-4e5b-b506-33bbf41b0d50@postgrespro.ru>
 <CAPpHfdtLk5M4FV6C33DnBusWpsbwwmrQ83mpu7N8PZMupbftyw@mail.gmail.com>
 <CAPpHfdtB9L1C7HLE30WDQfQQgUZo5P+5=9kLr5vQSpDZ-2AV_A@mail.gmail.com>
 <ZilrByTp-pbz6Mvf@pryzbyj2023> <CALT9ZEEwUkuhyxu2a1S7DYXZqfcy99q78q6BgvNRtpkY=VhfVQ@mail.gmail.com>
 <CAPpHfduYuYECrqpHMgcOsNr+4j3uJK+JPUJ_zDBn-tqjjh3p1Q@mail.gmail.com> <0520c72e-8d97-245e-53f9-173beca2ab2e@gmail.com>
In-Reply-To: <0520c72e-8d97-245e-53f9-173beca2ab2e@gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Sun, 28 Apr 2024 14:36:51 +0300
Message-ID: <CAPpHfdsC3Ci5ece78c9+sPW-8+Bb0V=FzMpgxb7QxcBWHVPdCA@mail.gmail.com>
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Dmitry Koval <d.koval@postgrespro.ru>, Justin Pryzby <pryzby@telsasoft.com>, 
	Robert Haas <robertmhaas@gmail.com>, Pavel Borisov <pashkin.elfe@gmail.com>, 
	pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAPpHfdsC3Ci5ece78c9%2BsPW-8%2BBb0V%3DFzMpgxb7QxcBWHVPdCA%40mail.gmail.com>
Precedence: bulk

On Sun, Apr 28, 2024 at 2:00=E2=80=AFPM Alexander Lakhin <exclusion@gmail.c=
om> 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 =3D 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