On Tue, May 19, 2015 at 12:29 PM, Andres Freund <and...@anarazel.de> wrote: > On 2015-05-19 10:53:10 -0400, Robert Haas wrote: >> That seems like a kludge to me. If the cookie leaks out somhow, which >> it will, then it'll be insecure. I think the way to do this is with a >> protocol extension that poolers can enable on request. Then they can >> just refuse to forward any "reset authorization" packets they get from >> their client. There's no backward-compatibility break because the >> pooler can know, from the server version, whether the server is new >> enough to support the new protocol messages. > > That sounds like a worse approach to me. Don't you just need to hide the > session authorization bit in a function serverside to circumvent that?
I'm apparently confused. There's nothing you can do to maintain security against someone who can load C code into the server. I must be misunderstanding you. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
