On Tue, May 26, 2015 at 10:06:59PM -0400, Robert Haas wrote: > On Sat, May 23, 2015 at 8:14 PM, Noah Misch <n...@leadboat.com> wrote: > > On Tue, May 19, 2015 at 04:49:26PM -0400, Robert Haas wrote: > >> A protocol extension avoids all of that trouble, and can be target for > >> 9.6 just like any other approach we might come up with. I actually > >> suspect the protocol extension will be FAR easier to fully secure, and > >> thus less work, not more. > > > > All true. Here's another idea. Have the pooler open one additional > > connection, for out-of-band signalling. Add a pair of functions: > > > > pg_userchange_grant(recipient_pid int, "user" oid) > > pg_userchange_accept(sender_pid int, "user" oid) > > > > To change the authenticated user of a pool connection, the pooler would call > > pg_userchange_grant in the signalling connection and pg_userchange_accept in > > the target connection. This requires no protocol change or confidential > > nonce. The inevitably-powerful signalling user is better insulated from > > other > > users, because the pool backends have no need to become that user at any > > point. Bugs in the pooler's protocol state machine are much less likely to > > enable privilege escalation. On the other hand, it can't be quite as fast > > as > > the other ideas on this thread. > > I'm sure this could be made to work, but it would require complex > signalling in return for no obvious value. I don't see avoiding a > protocol extension as particularly beneficial. New protocol messages > that are sent by the server cause a hard compatibility break for > clients, but new protocol messages that are client-initiated and late > enough in the protocol flow that the client knows the server version > have no such problem.
I didn't realize a protocol addition could be that simple, but you're right. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers