Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC
| От | Greg Sabino Mullane |
|---|---|
| Тема | Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC |
| Дата | |
| Msg-id | CAKAnmm+SrS1=ggcc9qCAXd=uzJWzwH_CciM+aRr-PtDZjrEuRA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC
|
| Список | 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 inpublic-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 по дате отправления: