Thread: Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications

Hi all,

at my company we have the same problem as the original poster. We also
set up views for system tables in the pg_catalog namespace and now
can't update pg_dump, because it then will stop working.

I see the problem description [1] and I see how it was solved but I do
not really understand the problem.

1) Let's assume that I'm an unprivileged DB user that runs pg_dump.
Then a superuser can do what ever he wants with my data and all
content inside the cluster so protecting me against a malicious
superuser doesn't make any sense. Protecting me against myself
changing stuff under pg_catalog doesn't seem to make sense either.

2) Next let's assume that I'm a superuser. Why would I then allow
users to change anything in the pg_catalog namespace? Changing
anything under pg_catalog should be out of scope for any unprivileged
user and so in that case I as a superuser running `pg_dump` will not
be affected by pg_dump inspecting system tables either, since they
would be unchanged.

So if there's no attack scenario, why then "fix" stuff?

I have seen in [1] that "the PostgreSQL project thanks Noah Misch for
reporting this problem" and have searched the mailing lists for that
report or a discussion of the problem but haven't been able to find
anything.

Can anybody please shine a light on what the actual attack scenario
would be respectively what I'm missing above in 1) and 2) or can
provide a pointer to the discussion of the problem?

Thank you!

Post Scriptum: There's a non-namespaced/schematized query at [4],
however I guess it's really just me not understanding the pg_dump
code...

[1] https://www.postgresql.org/support/security/CVE-2024-7348/
[2]
https://github.com/postgres/postgres/commit/66e94448abec3aad04faf0a79cab4881ae08e08a#diff-36e3806266f5e832b422f878e1d7fef4ebeea2143b1733ea3fa2f90a99bad5c5R1363
[3] https://github.com/postgres/postgres/blob/master/src/bin/pg_dump/pg_dump.c
[4]
https://github.com/postgres/postgres/blob/53a49365052026907afff7613929710d1e7f0da0/src/bin/pg_dump/pg_dump.c#L1723C18-L1723C32

> On 4 Feb 2025, at 15:43, Georgy Artos <georgyartos@gmail.com> wrote:

> Post Scriptum: There's a non-namespaced/schematized query at [4],
> however I guess it's really just me not understanding the pg_dump
> code...

> [4]
https://github.com/postgres/postgres/blob/53a49365052026907afff7613929710d1e7f0da0/src/bin/pg_dump/pg_dump.c#L1723C18-L1723C32

Thanks for the report, any such query should be fixed.  In this case it seems
fine, partition_tree is set up as a recursive common table expression a few
lines earlier in the function:

  if (with_child_tables)
  {
      appendPQExpBuffer(query, "WITH RECURSIVE partition_tree (relid) AS (\n");
  }

--
Daniel Gustafsson