Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC

På torsdag 12. september 2024 kl. 16:10:26, skrev Christophe Pettus < x...@thebuild.com >: > On Sep 12, 2024, at 06:58, Greg Sabino Mullane wrote: > > But if it works for you, go ahead. As Tom said, it will work 95% of the time. But it will break things that should

Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC

> On Sep 12, 2024, at 06:58, Greg Sabino Mullane wrote: > > But if it works for you, go ahead. As Tom said, it will work 95% of the time. > But it will break things that should work, and it will not prevent the > ability to get the information in other ways. To be clear, we never recommend

Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC

On Thu, Sep 12, 2024 at 3:53 PM Greg Sabino Mullane wrote: > On Thu, Sep 12, 2024 at 9:12 AM Dominique Devienne > wrote: >> On Thu, Sep 12, 2024 at 3:06 PM Greg Sabino Mullane >> wrote: >> > (Also note that determining if a database or user exists does not even >> > require a successful login

Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC

On Thu, Sep 12, 2024 at 9:21 AM Andreas Joseph Krogh wrote: > Yes, it *is* theater, but that doesn't prevent “compliance people” to > care about it. We have to take measures to prevent “information leaks”. > *shrug* Then the compliance people are not good at their jobs, frankly. But if it works

Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC

On Thu, Sep 12, 2024 at 9:12 AM Dominique Devienne wrote: > On Thu, Sep 12, 2024 at 3:06 PM Greg Sabino Mullane > wrote: > > (Also note that determining if a database or user exists does not even > require a successful login to the cluster.) > > Hi. How so? I was not aware of such possibilities.

Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC

På torsdag 12. september 2024 kl. 15:05:48, skrev Greg Sabino Mullane < htamf...@gmail.com >: On Thu, Sep 12, 2024 at 12:52 AM Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: I know PG is not designed for this, but I have this requirement nonetheless… I think

Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC

On Thu, Sep 12, 2024 at 3:06 PM Greg Sabino Mullane wrote: > (Also note that determining if a database or user exists does not even > require a successful login to the cluster.) Hi. How so? I was not aware of such possibilities. Can you please give pointers (docs, examples) of this? Thanks, --D

Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC

On Thu, Sep 12, 2024 at 12:52 AM Andreas Joseph Krogh 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.

Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC

rg Subject: Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC Andreas Joseph Krogh writes: > Motivation: I have PowerBI users, with a separate ‘reporting’-role, accessing > a database and I want to prevent them from listing all tables, users, > databases > a

Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC

Thanks for info. 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”. Maybe not revoking access to all the tables in the schemas, but the “most obvious ones”, like pg_use

Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC

Andreas Joseph Krogh writes: > Motivation: I have PowerBI users, with a separate ‘reporting’-role, accessing > a database and I want to prevent them from listing all tables, users, > databases > and view-definitions (to not see the underlying query). Postgres is not designed to support this re

Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC

Hei all. Motivation: I have PowerBI users, with a separate ‘reporting’-role, accessing a database and I want to prevent them from listing all tables, users, databases and view-definitions (to not see the underlying query). I'm evaluating this: REVOKE SELECT ON ALL TABLES IN SCHEMA pg_cata