On Fri, Mar 6, 2015 at 12:50:14PM -0800, Josh Berkus wrote: > On 03/06/2015 08:19 AM, Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > >> Stephen Frost wrote: > >> Sure. I was thinking we would have some mechanism to authenticate the > >> connection as coming from a pooler that has been previously authorized; > >> something simple as a new pg_hba.conf entry type for "poolers" that are > >> only authorized to connect to such-and-such databases, perhaps limit to > >> such-and-such users, etc. > > > > Well, server-side, we already have that- have pgbouncer run on the > > database server (something which I'm typically in favor of anyway) and > > use 'peer'. If it supported TLS then it could use certificates instead. > > The question is what to do after the pooler has connected and that's > > actually a generic issue which goes beyond poolers and into > > applications, basically, "how can I re-authenticate this connection > > using a different role." We have SET ROLE, but that gives a lot of > > power to the role the pooler logs in as. It'd definitely be neat to > > provide a way to use SCRAM or similar to do that re-authentication after > > the initial connection. > > Using pgbouncer on the DB server is common, but less common that using > it on an intermediate server or even the app server itself. So anything > we create needs to be implementable with all three configurations in > some way.
I think the best solution to this would be to introduce a per-cluster salt that is used for every password hash. That way, you could not replay a pg_authid hash on another server _unless_ you had manually assigned the same cluster salt to both servers, or connection pooler. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
