Re: Fwd: Identify system databases

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Dominique Devienne <ddevienne(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Igor Korot <ikorot01(at)gmail(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Fwd: Identify system databases
Date: 2025-04-16 20:04:10
Message-ID: ae583b0b04be3f12714a2f2e003b8ee9d638d305.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 2025-04-16 at 17:06 +0200, Dominique Devienne wrote:
> So in a way, you guys are saying one should never REVOKE CONNECT ON
> DATABASE FROM PUBLIC?

No, not at all.

> All my DBs are not PUBLIC-accessible.
> And inside my DBs, I try to revoke everything from PUBLIC
> (USAGE ON TYPES, EXECUTE ON ROUTINES).
> Nor do I use the public schema.
> And I never use the "built-in" postgres database.
> Basically I want all GRANTs to be explicit.
>
> Given the above, I'd want to not provide access to the postgres DB too.
> Yet have a way to discover which DBs I can connect to, from the "cluster only".
> Naively.
>
> Sounds like you are saying use the "postgres" DB for that, and move on.

It is just fine to restrict access to databases as much as you want.

You just need access to a database if you want to run SQL statements,
be that SELECT or CREATE DATABASE. It's as simple as that.

Restricting access is not wrong per se, but if you randomly restrict
access to everything, that's not so much a security measure as a way
to make the database unusable.

I see no value in restricting USAGE on the data type "text" or EXECUTE
on the function "upper()". Modifying system objects is not recommended
and can lead to trouble.

Yours,
Laurenz Albe

In response to

Browse pgsql-general by date

  From Date Subject
Next Message 王 博 2025-04-17 05:17:18 Request for official clarification on SQL parameter parsing changes in PostgreSQL 15 and 16
Previous Message Nico Williams 2025-04-16 19:59:37 Re: Best Tool for PostgreSQL Auditing and Storing Audit Logs Separately