| From: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
|---|---|
| To: | Andreas Joseph Krogh <andreas(at)visena(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC |
| Date: | 2024-09-12 13:05:48 |
| Message-ID: | CAKAnmm+SrS1=ggcc9qCAXd=uzJWzwH_CciM+aRr-PtDZjrEuRA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, Sep 12, 2024 at 12:52 AM Andreas Joseph Krogh <andreas(at)visena(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dominique Devienne | 2024-09-12 13:11:59 | Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC |
| Previous Message | Rich Shepard | 2024-09-12 12:41:32 | Re: Removing duplicate rows in table |