Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC - Mailing list pgsql-general

From Greg Sabino Mullane
Subject Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC
Date
Msg-id CAKAnmm+SrS1=ggcc9qCAXd=uzJWzwH_CciM+aRr-PtDZjrEuRA@mail.gmail.com
Whole thread Raw
In response to Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC
List pgsql-general
On Thu, Sep 12, 2024 at 12:52 AM Andreas Joseph Krogh <andreas@visena.com> wrote:
I know PG is not designed for this, but I have this requirement nonetheless…
I think preventing “most users and tools" from seeing/presenting this information is “good enough”.

As pointed out, there are very many workarounds. This is security theater.

If read-access (SELECT) on views in public-schema will still works, and pg_dump/restore etc. also works, this sounds like a solution to me.

pg_dump will absolutely not work without access to the system catalogs.

If you want to prevent information, stop direct access and make the application call user functions.

(Also note that determining if a database or user exists does not even require a successful login to the cluster.)

Cheers,
Greg

pgsql-general by date:

Previous
From: Rich Shepard
Date:
Subject: Re: Removing duplicate rows in table
Next
From: Dominique Devienne
Date:
Subject: Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC