[ redirecting to -bugs ]
=?iso-8859-1?Q?F=E4rber=2C_Franz-Josef_=28StMUK=29?= <Franz-Josef.Faerber@stmuk.bayern.de> writes:
> My minimal example goes like this: On the fresh container, execute
> ```sql
> CREATE ROLE limitedrole;
> CREATE SCHEMA ext_trgm;
> CREATE EXTENSION pg_trgm SCHEMA ext_trgm;
> GRANT USAGE ON SCHEMA ext_trgm TO limitedrole;
> SET ROLE limitedrole;
> CREATE TABLE x(y text);
> CREATE INDEX ON x USING gist(y ext_trgm.gist_trgm_ops);
> ```
> Dump the database with `pg_dump > /tmp/x`, then do
> ```sql
> DROP SCHEMA ext_trgm CASCADE; DROP TABLE x;
> ```
> (or alternatively create a fresh database and do a ` CREATE ROLE limitedrole;`)
> Then try to restore the dump with `cat /tmp/x | psql`.
> On version 14.2, this succeeds.
> On version 14.3, this fails with "ERROR: permission denied for schema ext_trgm".
I think what is happening here is that parse analysis of the index
expression is now being done as the owner of the table (already assigned
as limitedrole), as a consequence of the patch for CVE-2022-1552.
So basically, that patch has completely broken pg_dump's scheme for
when it can issue GRANTs. I'm not sure there is a simple fix :-(.
We could issue the GRANTs earlier but that is going to break some
other use-cases, if memory serves.
regards, tom lane
