Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)

On Tue, Nov 5, 2019 at 10:02 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> There's a reason the SQL standard defines SET SESSION AUTHORIZATION but
> no RESET SESSION AUTHORIZATION: once you enter a security context, you
> cannot escape it.  ISTM that essentially we broke feature F321 "User
> authorization" by adding RESET into the mix.  (I think RESET ROLE breaks
> the spirit of feature T331 too.)  The SQL:2016 standard describes how
> this is supposed to work in Foundation "4.40.1.1 SQL-session
> authorization identifiers" (same section is numbered 4.35.1.1 in
> SQL:2011), and ISTM we made a huge mess of it.
>
> I don't see how to fix it, though.  If we were to adopt the standard's
> mechanism, we'd probably break tons of existing code.

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.