From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Standards compliance of SET ROLE / SET SESSION AUTHORIZATION |
Date: | 2020-02-14 21:19:57 |
Message-ID: | e62d7d78-1724-11bd-75cf-b212cc7de029@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/14/20 4:01 PM, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> It wouldn't be difficult to introduce a new protocol-level option that
>> prohibits RESET SESSION AUTHORIZATION; and it would also be possible
>> to introduce a new protocol message that has the same effect as RESET
>> SESSION AUTHORIZATION. If you do those two things, then it's possible
>> to create a sandbox which the end client cannot escape but which the
>> pooler can escape easily.
> ...
> SET SESSION AUTHORIZATION foo PERMANENT;
> ... A protocol-level message
> to set session auth could also be possible, of course.
I'll once again whimper softly and perhaps ineffectually that an
SQL-exposed equivalent like
SET SESSION AUTHORIZATION foo WITH RESET COOKIE 'lkjhikuhoihkihlj';
would seem to suit the same purpose, with the advantage of being
immediately usable by any kind of front- or middle-end code the
instant there is a server version that supports it, without having
to wait for something new at the protocol level to trickle through
to n different driver implementations.
Regards,
-Chap
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-02-14 21:35:30 | Re: Standards compliance of SET ROLE / SET SESSION AUTHORIZATION |
Previous Message | James Coleman | 2020-02-14 21:14:01 | Re: [DOC] Document auto vacuum interruption |