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

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Request for comment on setting binary format output per session
Дата
Msg-id d412498f5b70ee6edbaf60d264e9c130710396e5.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Request for comment on setting binary format output per session  (Dave Cramer <davecramer@gmail.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Brar Piening
Дата:
Сообщение: Re: doc: add missing "id" attributes to extension packaging page
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Transparent column encryption