Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications - Mailing list pgsql-bugs

From Georgy Artos
Subject Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
Date
Msg-id CAHZ8FghN_NOAZFnvdJXc4UB7F1AVLRJxB69D6AE3JCYDAEi24w@mail.gmail.com
Whole thread Raw
Responses Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
List pgsql-bugs
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



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #18793: PLpgSQL Function Returning Type of Table is not match for varchar(n) data type via Return Query
Next
From: Daniel Gustafsson
Date:
Subject: Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications