From: Antonin Houska <ah@cybertec.at>
To: Greg Sabino Mullane <htamfids@gmail.com>
cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Subject: Re: POC: Carefully exposing information without authentication
In-reply-to: 
 <CAKAnmm+T-CEDLmRezWfH-7ZEsFfD_kU2KY1TgB288K+wprB_4Q@mail.gmail.com>
References: 
 <CAKAnmm+T-CEDLmRezWfH-7ZEsFfD_kU2KY1TgB288K+wprB_4Q@mail.gmail.com>
Comments: In-reply-to Greg Sabino Mullane <htamfids@gmail.com>
   message dated "Thu, 29 May 2025 10:32:57 -0400."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <21075.1748617330.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 30 May 2025 17:02:11 +0200
Message-ID: <21076.1748617331@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/21076.1748617331%40localhost>
Precedence: bulk

Greg Sabino Mullane <htamfids@gmail.com> wrote:

> Proposal: Allow a carefully curated selection of information to be shown=
 without authentication.
> =

> A common task for an HA system or a load balancer is to quickly determin=
e which of your Postgres clusters is the primary, and which are the
> replicas. The canonical way to do this is to log in to each server with =
a valid username and password, and then run pg_is_in_recovery().
> That's a lot of work to determine if a server is a replica or not, and i=
t struck me that this true/false information about a running cluster is no=
t
> super-sensitive information. In other words, would it really be wrong if=
 there was a way to advertise that information without having to log in?
> I toyed with the idea of Postgres maintaining some sort of signal file, =
but then I realized that we already have a process, listening on a known
> port, that has that information available to us.
> =

> Thus, this POC (proof of concept), which lets the postmaster scan for in=
coming requests and quickly handle them *before* doing forking and
> authenticating. We scan for a simple trigger string, and immediately ret=
urn the information to the client.

Why is it important not to fork?  My understanding is that pg_is_ready als=
o
tries to start a regular connection, i.e. forks a new backend. I think thi=
s
functionality would fit into libpq. (I've got no strong opinion on the amo=
unt
of information to be revealed this way. In any case, a GUC to enable the
feature only if the DBA wants it makes sense.)

-- =

Antonin Houska
Web: https://www.cybertec-postgresql.com