Re: BUG #18249: pg_dump/pg_restore single schema with function1 calling function2

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: wilma(dot)wantren(at)web(dot)de, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18249: pg_dump/pg_restore single schema with function1 calling function2
Date: 2023-12-15 13:03:43
Message-ID: a5b6415b5d1f45e79600b8ad4d369fecd9c9f8d2.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, 2023-12-15 at 09:09 +0000, PG Bug reporting form wrote:
> [...] pg_dump/pg_restore [...]
>
> But there is one problem: we have a database function function1, which calls
> another function function2. The call is made without a schema prefix because
> these are just two functions that we make available to the customers and we
> don't think an extra schema for these two functions is worthwhile. However,
> function1 is used in an index and the restore of the index fails if there is
> data in the corresponding table column. This is because pg_dump/pg_restore
> set the search_path to '' when restoring, which means that function1 cannot
> find the function2.
> Is there any way to solve this?

This is a bug, but not a PostgreSQL bug. The bug is in your object definition.
Relying on "search_path" like that is a security risk, particularly in
functions used in an index definition. If a privileged user inserts a value
in an environment where somebody else can manipulate "search_path", anything
can happen.

The best fix is to

ALTER FUNCTION ... SET search_path = only, safe, schemas;

Yours,
Laurenz Albe

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Wetmore, Matthew (CTR) 2023-12-15 14:29:38 BUG #18249: pg_dump/pg_restore single schema with function1 calling function2
Previous Message Alexander Lakhin 2023-12-15 13:00:01 Re: BUG #18246: pgstathashindex() attempts to read invalid file for hash index attached to partitioned table