Re: Add more sanity checks around callers of changeDependencyFor()

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Heikki Linnakangas <hlinnaka@iki.fi>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-07-06T17:09:20Z
Lists: pgsql-hackers
Hi,

On 2023-07-05 14:10:42 +0900, Michael Paquier wrote:
> On Tue, Jul 04, 2023 at 02:40:04PM -0400, Tom Lane wrote:
> > Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> >> Hmm, shouldn't we disallow moving the function to another schema, if the
> >> function's schema was originally determined at extension creation time?
> >> I'm not sure we really want to allow moving objects of an extension to a
> >> different schema.
> > 
> > Why not?  I do not believe that an extension's objects are required
> > to all be in the same schema.
> 
> Yes, I don't see what we would gain by putting restrictions regarding
> which schema an object is located in, depending on which schema an
> extension uses.

Well, it adds an exploitation opportunity. If other functions in the extension
reference the original location (explicitly or via search_path), somebody else
can create a function there, which might be called from a more privileged
context. Obviously permissions limit the likelihood of this being a real
issue.

I also don't think pg_dump will dump the changed schema, which means a
dump/restore leads to a different schema - IMO something to avoid.

Greetings,

Andres Freund



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add more sanity checks with callers of changeDependencyFor()

  2. Fix ALTER EXTENSION SET SCHEMA with objects outside an extension's schema