Re: Request for comment on setting binary format output per session - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Request for comment on setting binary format output per session
Date
Msg-id d412498f5b70ee6edbaf60d264e9c130710396e5.camel@j-davis.com
Whole thread Raw
In response to Re: Request for comment on setting binary format output per session  (Dave Cramer <davecramer@gmail.com>)
Responses Re: Request for comment on setting binary format output per session  (Merlin Moncure <mmoncure@gmail.com>)
Re: Request for comment on setting binary format output per session  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, 2023-03-29 at 08:17 -0400, Dave Cramer wrote:
> I'm starting to wonder about the utility of the protocol extension
> mechanism? 

I'm starting to agree that the awkwardness around connection poolers is
a problem. If that's the case, I'm wondering if the protocol extensions
will ever be useful.

What I'm worried about with the GUC is that an attacker may be able to
start with a SQL injection attack, and then use the GUC to confuse a
client in a way that further escalates privileges. Is that a reasonable
fear?

A couple ideas to mitigate that concern with the GUC:

1. Fix our own clients, like psql, to check for binary data they can't
process.

2. Communicate (after the patch is committed) with client library
maintainers to see that they behave sanely when they receive binary
data unexpectedly.

3. Require that the binary_formats parameter is set very early, either
during connection startup or right after a DISCARD statement. A bit of
a hack, but may help. Not sure it really solves my security concern
because they'd just need to modify their SQL injection to also include
a DISCARD statement.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Brar Piening
Date:
Subject: Re: doc: add missing "id" attributes to extension packaging page
Next
From: Peter Eisentraut
Date:
Subject: Re: Transparent column encryption