Re: Extension pg_trgm, permissions and pg_dump order
От | Tom Lane |
---|---|
Тема | Re: Extension pg_trgm, permissions and pg_dump order |
Дата | |
Msg-id | 1961551.1653498155@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Extension pg_trgm, permissions and pg_dump order
|
Список | pgsql-bugs |
[ 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
В списке pgsql-bugs по дате отправления: