Subject: Re: POC: Carefully exposing information without authentication

From: Antonin Houska <[email-masked]>
Date: Fri, 09 Jan 2026 14:56:38 +0100

Greg Sabino Mullane <[email-masked]> wrote:

> Version 4 attached, rebased to account for new tests, plus a new instra-test
> check to make sure LWP::UserAgent is available before running.

I'm still not sure it's necessary to handle the problem at socket level. I
imagine it can be implemented this way:

1. Add a new field to the PGconn structure, indicating that the client is only
requesting the server status information, and adjust pg_isready so it sets
this option.

2. Adjust libpq frontend (pqBuildStartupPacket3) so it adds the corresponding
option to the startup packet.

3. On server, if ProcessStartupPacket() sees that option, call ereport(FATAL)
with a specific error code, and let the appropriate GUCs control the contents
of the error message. pg_isready would then just print out the message.

I haven't tried to write any code, so it's possible that I'm missing
something.

Regarding configuration, I'd prefer a single GUC. The value can be a
comma-separated list of keywords, each representing particular piece of
information to be exposed.

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

---

From: Greg Sabino Mullane <[email-masked]>
Date: Fri, 9 Jan 2026 09:15:48 -0500

On Fri, Jan 9, 2026 at 8:56 AM Antonin Houska <[email-masked]> wrote:

> 1. Add a new field to the PGconn structure

This kind of defeats one of the major strengths of this patch, which is
allowing systems that don't speak the protocol to get at this information.

> information to be exposed.

Yes, I could see some advantages to that, although I still like the
simplicity of separate boolean values. I've no strong feelings either way.
Let's see if others weigh in.

Thanks for looking over this patch!

Cheers,
Greg

---

From: Greg Sabino Mullane <[email-masked]>
Date: Tue, 17 Feb 2026 14:42:48 -0500

Please find attached a rebased and lightly reworked version of this patch.
The most significant change is the test file now uses IO::Socket::INET via
$node->raw_connect. Also changed to allow case-insensitive calls, moved to
a better docs group, moved the defines and typedefs up, and changed the
exit to just a simple _exit()

Cheers,
Greg

---

From: Andres Freund <[email-masked]>
Date: Tue, 17 Feb 2026 14:58:22 -0500

Hi,

On 2026-02-17 14:42:48 -0500, Greg Sabino Mullane wrote:
> Subject: [PATCH] Allow specific information to be output directly by Postgres.

I strongly encourage you to include a justification for why this is desirable,
so a casual reviewer doesn't have to reread the thread.

> @@ -148,6 +172,14 @@ BackendInitialize(ClientSocket *client_sock, CAC_state cac)
>  	StringInfoData ps_data;
>  	MemoryContext oldcontext;
>  
> +	/*
> +	 * Scan for a simple GET / HEAD request. If this is detected and
> +	 * handled, we are done and can immediately exit
> +	 */
> +	if ((expose_recovery || expose_sysid || expose_version)
> +		&& ExposeInformation(client_sock->sock))
> +		_exit(0); /* Safe to use exit: no state or resources created yet */
> +
>  	/* Tell fd.c about the long-lived FD associated with the client_sock */
>  	ReserveExternalFD();
>

What about direct TLS connections?

How can a cluster coordinator trust unauthenticated plain text communication
that can just be man-in-the-middled?

It's not obvious that it's a good idea to expose this on the same socket as
normal client connections.  IMO you'd want to limit this to a smaller set of
interfaces than normal client connections.

> +/*
> + * ExposeInformation
> + *
> + * Handle early socket probe before full backend startup.
> + * Responds to small set of predefined endpoints (e.g. GET /info)
> + *
> + * Requires at least one "expose_" GUC to be true.
> + *
> + * Returns true if any endpoint is recognized.
> + */
> +
> +static bool
> +ExposeInformation(pgsocket fd)
> +{
> +	static endpoint_action endpoint_actions[] =
> +	{
> +		{
> +			"HEAD /replica", &expose_recovery, EXPOSE_HEAD_REPLICA
> +		},
> +		{
> +			"GET /replica", &expose_recovery, EXPOSE_GET_REPLICA
> +		},
> +		{
> +			"GET /sysid", &expose_sysid, EXPOSE_GET_SYSID
> +		},
> +		{
> +			"GET /version", &expose_version, EXPOSE_GET_VERSION
> +		},
> +		{
> +			"GET /info", NULL, EXPOSE_GET_ALL
> +		}
> +	};
> +
> +	ssize_t		n;
> +	char		buf[EXPOSE_MAX_QUERY + 1];
> +	ExposeReturnType	type;
> +
> +	Assert(expose_recovery || expose_sysid || expose_version);
> +
> +	do
> +	{
> +		n = recv(fd, buf, EXPOSE_MAX_QUERY, MSG_PEEK);
> +	} while (n < 0 && errno == EINTR);
>
> +	/*
> +	 * Leave as soon as possible if no chance we are interested.
> +	 * (we also leave on partial reads from slow clients)
> +	 * We also simply return false for n == -1
> +	 */
> +	if (n < EXPOSE_MIN_QUERY)
> +		return false;

IIRC the socket is in blocking mode at this point (that's only changed in
pq_init()), therefore this might actually block?  While it's unlikely, I don't
see any guarantee that a single receive would actually get the whole message
from the client either, so this seems like it might fail spuriously.

> diff --git a/src/backend/utils/misc/guc_parameters.dat b/src/backend/utils/misc/guc_parameters.dat
> index 271c033952e..3e99d9f6b7c 100644
> --- a/src/backend/utils/misc/guc_parameters.dat
> +++ b/src/backend/utils/misc/guc_parameters.dat
> @@ -1010,6 +1010,25 @@
>    boot_val => 'false',
>  },
>  
> +{ name => 'expose_recovery', type => 'bool', context => 'PGC_SIGHUP', group => 'CONN_AUTH_AUTH',
> +  short_desc => 'Exposes if the server is in recovery mode without a login.',
> +  variable => 'expose_recovery',
> +  boot_val => 'false',
> +},
> +
> +{ name => 'expose_sysid', type => 'bool', context => 'PGC_SIGHUP', group => 'CONN_AUTH_AUTH',
> +  short_desc => 'Exposes the system identifier without a login.',
> +  variable => 'expose_sysid',
> +  boot_val => 'false',
> +},
> +
> +{ name => 'expose_version', type => 'bool', context => 'PGC_SIGHUP', group => 'CONN_AUTH_AUTH',
> +  short_desc => 'Exposes the server version without a login.',
> +  variable => 'expose_version',
> +  boot_val => 'false',
> +},
> +

If we were to do this, I'd recommend a single expose GUC that has the
different values as a comma separated list, instead a growing list of GUCs.

Greetings,

Andres Freund

---

From: Greg Sabino Mullane <[email-masked]>
Date: Tue, 24 Mar 2026 21:59:19 -0400

Thank you for looking over this. New version attached.

> What about direct TLS connections?

Not handled.

How can a cluster coordinator trust unauthenticated plain text
> communication that can just be man-in-the-middled?
>

They cannot. But that's why this is only exposing non-critical information.
Right now the security scanners that are banging on port 5432 and scraping
the returned error lines are not worried about man-in-the-middle. :)
Obviously, if your threat model is people capturing and modifying
non-encrypted traffic to your Postgres server, you would not use this.

> normal client connections.  IMO you'd want to limit this to a smaller set
> of interfaces than normal client connections.
>

I'm not entirely clear what that smaller set would mean in practice.

> pq_init()), therefore this might actually block?  While it's unlikely, I
> don't see any guarantee that a single receive would actually get the whole
> message from the client either, so this seems like it might fail spuriously.
>

Yes, there are some very unlikely edge cases, but this is meant to be good
enough, not a perfectly bulletproof HTTP server. Clients should try again
on failures. Which if they do occur for this trivial amount of traffic
probably indicates much bigger problems.

> different values as a comma separated list, instead a growing list of GUCs.

Done - see attached for a new version which consolidates the bools into a
single comma-separated GUC called "expose_information". I also added some
docs, and changed the "replica" to return "REPLICA" instead of "RECOVERY".
I like the latter better, but replica lines up better with existing tools.

-- 
Cheers,
Greg