On Thu, 2022-12-15 at 12:31 +0300, Pavel Luzanov wrote:
> I think the approach that Nathan implemented [1] for TOAST tables
> in the latest version can be used for partitioned tables as well.
> Skipping the privilege check for partitions while working with
> a partitioned table. In that case we would get exactly the same
> behavior
> as for INSERT, SELECT, etc privileges - the MAINTAIN privilege would
> work for
> the whole partitioned table, but not for individual partitions.
There is some weirdness in 15, too:
create user foo;
create user su superuser;
grant all privileges on schema public to foo;
\c - foo
create table p(i int) partition by range (i);
create index p_idx on p (i);
create table p0 partition of p for values from (0) to (10);
\c - su
create table p1 partition of p for values from (10) to (20);
\c - foo
-- possibly weird because the 15 inserts into p1 (owned by su)
insert into p values (5), (15);
-- all these are as expected:
select * from p; -- returns 5 & 15
insert into p1 values(16); -- permission denied
select * from p1; -- permission denied
-- the following commands seem inconsistent to me:
vacuum p; -- skips p1 with warning
analyze p; -- skips p1 with warning
cluster p using p_idx; -- silently skips p1
reindex table p; -- reindexes p0 and p1 (owned by su)
-- RLS is also bypassed
\c - su
grant select, insert on p1 to foo;
alter table p1 enable row level security;
create policy odd on p1 using (i % 2 = 1) with check (i % 2 = 1);
\c - foo
insert into p1 values (16); -- RLS error
insert into p values (16); -- succeeds
select * from p1; -- returns only 15
select * from p; -- returns 5, 15, 16
The proposal to skip privilege checks for partitions would be
consistent with INSERT, SELECT, REINDEX that flow through to the
underlying partitions regardless of permissions/ownership (and even
RLS). It would be very minor behavior change on 15 for this weird case
of superuser-owned partitions, but I doubt anyone would be relying on
that.
+1.
I do have some lingering doubts about whether we should even allow
inconsistent ownership/permissions. But I don't think we need to settle
that question now.
--
Jeff Davis
PostgreSQL Contributor Team - AWS
