On Tue, May 26, 2015 at 10:06:59PM -0400, Robert Haas wrote:
> On Sat, May 23, 2015 at 8:14 PM, Noah Misch <noah@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.