Re: Request for comment on setting binary format output per session

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Dave Cramer <davecramer(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Request for comment on setting binary format output per session
Date: 2023-03-29 16:04:19
Message-ID: d412498f5b70ee6edbaf60d264e9c130710396e5.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2023-03-29 16:08:29 Re: Transparent column encryption
Previous Message Brar Piening 2023-03-29 16:03:48 Re: doc: add missing "id" attributes to extension packaging page