From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, GurjeetSingh <gurjeet(at)singh(dot)im> |
Subject: | Re: Fix search_path for all maintenance commands |
Date: | 2023-07-13 18:56:00 |
Message-ID: | 2cf41c8edeaaf7acb757095e6eceab8ae926f3da.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2023-07-06 at 18:39 -0700, Jeff Davis wrote:
> * The fix might not go far enough or might be in the wrong place. I'm
> open to suggestion here, too. Maybe we can make it part of the
> general
> function call mechanism, and can be overridden by explicitly setting
> the function search path? Or maybe we need new syntax where the
> function can acquire the search path from the session explicitly, but
> uses a safe search path by default?
I'm inclined to proceed with the current approach here, which is to
just fix search_path for maintenance commands. Other approaches may be
possible, but:
(a) We already special-case the way functions are executed for
maintenance commands in other ways -- we run the functions as the table
owner (even SECURITY INVOKER functions) and run them as a
SECURITY_RESTRICTED_OPERATION. Setting the search_path to a safe value
seems like a natural extension of that; and
(b) The lack of a safe search path is blocking other useful features,
such as the MAINTAIN privilege; and
(c) I don't see other proposals, aside from a few ideas I put forward
here[1], which didn't get any responses.
The current approach seemed to get support from Noah, Nathan, and Greg
Stark.
Concerns were raised by Gurjeet, Tom, and Robert in the 16 cycle; but
I'm not sure whether those objections were specific to the 16 cycle or
whether they are objections to the approach entirely. Comments?
Regards,
Jeff Davis
[1]
https://www.postgresql.org/message-id/6781cc79580c464a63fc0a1343637ed2b2b0cf09.camel%40j-davis.com
From | Date | Subject | |
---|---|---|---|
Next Message | Farias de Oliveira | 2023-07-13 19:14:32 | In Postgres 16 BETA, should the ParseNamespaceItem have the same index as it's RangeTableEntry? |
Previous Message | Dean Rasheed | 2023-07-13 17:30:59 | Re: MERGE ... RETURNING |