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

From: Dominique Devienne <ddevienne(at)gmail(dot)com>
To: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
Cc: Andreas Joseph Krogh <andreas(at)visena(dot)com>, 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 14:10:56
Message-ID: CAFCRh-_8P=Se_4F5VXn=Z9vc5Dj6+k+xd7HGtt5zsg_=Ltqiyw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Sep 12, 2024 at 3:53 PM Greg Sabino Mullane <htamfids(at)gmail(dot)com> wrote:
> On Thu, Sep 12, 2024 at 9:12 AM Dominique Devienne <ddevienne(at)gmail(dot)com> wrote:
>> On Thu, Sep 12, 2024 at 3:06 PM Greg Sabino Mullane <htamfids(at)gmail(dot)com> 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?
>
> psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: FATAL: role "eve" does not exist
> psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: FATAL: database "theater" does not exist
> psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: FATAL: password authentication failed for user "alice"

Ah silly me, I was thinking of something else.
Sure, "probing" for DB or USER names by attempting connecting is of
course an option.
Thanks, --DD

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Andreas Joseph Krogh 2024-09-12 14:13:26 Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC
Previous Message Christophe Pettus 2024-09-12 14:10:26 Re: Effects of REVOKE SELECT ON ALL TABLES IN SCHEMA pg_catalog FROM PUBLIC