On Tue, May 19, 2015 at 04:49:26PM -0400, Robert Haas wrote:
> On Tue, May 19, 2015 at 3:00 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> > As long as the cookie is randomly generated for each use, then I don't see a
> > practical problem with that approach.
>
> If the client sets the cookie via an SQL command, that command would
> be written to the log, and displayed in pg_stat_activity. A malicious
> user might be able to get it from one of those places.
>
> A malicious user might also be able to just guess it. I don't really
> want to create a situation where any weakess in pgpool's random number
> generation becomes a privilege-escalation attack.
>
> 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.