On Fri, Jan 13, 2017 at 7:39 PM, Karl Czajkowski <karlcz@xxxxxxx> wrote: > The concern was raised about the risk of the subsequent queries being > able to reverse the "set role" to subvert such authorization. Others > in the thread provided the common advice of parametric queries to > prevent query injection, but I think you need more than that. I think > one would like a stronger isolation between the connection > setup/security config layer and the fancier (and possibly flawed) > application layer. We struggle with this because all these mechanisms > are multiplexed as commands in one SQL connection, instead of having > an in-band versus out-of-band protocol layering available to the web > application, so the more risky data-dependent SQL can flow in-band > while the basic request-handler lifecycle could configure the security > context out-of-band. Wasn't there some previous discussion about the ability to have a form of SET ROLE that would specify that some token would be needed to do a successful RESET ROLE? (I don't remember whether people were leaning toward providing the token on the SET ROLE statement, or getting that as part of the return state.) If you made the token a suitably secure random value, and made an incorrect token on the RESET ROLE a FATAL error, it seems like it could be secure enough. You still need to have the ability to authenticate the client side connection in the connection pooler, and have the connection pooler connect to the server with a login with rights to do the appropriate SET ROLE (preferably without requiring superuser rights). -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
