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

Started by Georgy Artosabout 1 year ago2 messagesbugs
Jump to latest
#1Georgy Artos
georgyartos@gmail.com

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]https://www.postgresql.org/support/security/CVE-2024-7348/ 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]https://www.postgresql.org/support/security/CVE-2024-7348/ 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]https://github.com/postgres/postgres/blob/53a49365052026907afff7613929710d1e7f0da0/src/bin/pg_dump/pg_dump.c#L1723C18-L1723C32,
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

#2Daniel Gustafsson
daniel@yesql.se
In reply to: Georgy Artos (#1)

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