Re: pgsql: Fix search_path to a safe value during maintenance operations.
От | David G. Johnston |
---|---|
Тема | Re: pgsql: Fix search_path to a safe value during maintenance operations. |
Дата | |
Msg-id | CAKFQuwYocyEvpC=_0BgG3t9DVXNmzrWqBTLEov9zy4qW1239yg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Fix search_path to a safe value during maintenance operations. ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: pgsql: Fix search_path to a safe value during maintenance operations.
|
Список | pgsql-committers |
On Monday, June 12, 2023, David G. Johnston <david.g.johnston@gmail.com> wrote:
On Mon, Jun 12, 2023 at 5:40 PM Jeff Davis <pgsql@j-davis.com> wrote:On Mon, 2023-06-12 at 13:05 -0400, Noah Misch wrote:
> The timing was not great, but this is fixing a purported defect in an
> older
> v16 feature. If the MAINTAIN privilege is actually fine, we're all
> set for
> v16. If MAINTAIN does have a material problem that $SUBJECT had
> fixed, we
> should either revert MAINTAIN, un-revert $SUBJECT, or fix the problem
> a
> different way.
Someone with the MAINTAIN privilege on a table can use search_path
tricks against the table owner, if the code is susceptible, because
maintenance code runs with the privileges of the table owner.Only change the search_path if someone other than the table owner or superuser is running the command (which should only be possible via the new MAINTAIN privilege)?
On a related note, are we OK with someone using this privilege setting their own default_statistics_target?
My prior attempt to open up analyze had brought this up as a reason to avoid having someone besides the table owner allowed to analyze the table.
David J.
В списке pgsql-committers по дате отправления: