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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
