On 19/05/15 20:46, Andres Freund wrote:
On 2015-05-19 14:41:06 -0400, Robert Haas wrote:
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.
It very well might be me that's confused. But what's stopping a user
from doing a "RESET SESSION AUTHORIZATION;" in a DO block or something?
I guess you are intending that a RESET SESSION AUTHORIZATION is only
allowed on a protocol level when the protocol extension is in use?
If I understand Robert correctly, he was talking about setting and
resetting this on protocol level (with the assistance of pooler) so
there is no way to circumvent that from SQL no matter how you mask the
command. I think that idea is quite sound.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
