Re: pgsql: Fix search_path to a safe value during maintenance operations. - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: pgsql: Fix search_path to a safe value during maintenance operations.
Date
Msg-id fd425bbacb86a00b85aabcbaa78d55c55cbf6fc3.camel@j-davis.com
Whole thread Raw
In response to Re: pgsql: Fix search_path to a safe value during maintenance operations.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pgsql: Fix search_path to a safe value during maintenance operations.
List pgsql-hackers
On Mon, 2023-07-31 at 16:06 -0400, Robert Haas wrote:
> if you
> include in your search_path a schema to which some other user can
> write, you are pretty much agreeing to execute code provided by that
> user.

Agreed on all counts here. I don't think it's reasonable for us to try
to make such a setup secure, and I don't think users have much need for
such a setup anyway.

> One thing we might be able to do to prevent that sort of thing is to
> have a feature to prevent "accidental" code execution, as in the
> "function trust" mechanism proposed previously. Say I trust all users
> who can SET ROLE to me and/or who inherit my privileges. Additionally
> I can decide to trust users who do neither of those things by some
> sort of explicit declaration. If I don't trust a user then if I do
> anything that would cause code supplied by that user to get executed,
> it just errors out:
>
> ERROR: role "rhaas" should not execute arbitrary code provided by
> role "jconway"
> HINT: If this should be allowed, use the TRUST command to permit it.

+1, though I'm not sure we need an extensive trust mechanism beyond
what we already have with the SET ROLE privilege.

> And
> we probably also still need to find ways to control search_path in a
> lot more widely than we do today. Otherwise, even if stuff is
> technically secure, it may just not work.

+1.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Tristen Raab
Date:
Subject: Re: Correct the documentation for work_mem
Next
From: José Neves
Date:
Subject: RE: CDC/ETL system on top of logical replication with pgoutput, custom client