From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, José Luis Tallón <jltallon(at)adv-solutions(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: RFC: Non-user-resettable SET SESSION AUTHORISATION |
Date: | 2015-05-19 18:46:15 |
Message-ID: | 20150519184615.GF14931@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-05-19 14:41:06 -0400, Robert Haas wrote:
> On Tue, May 19, 2015 at 12:29 PM, Andres Freund <andres(at)anarazel(dot)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?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2015-05-19 18:51:31 | Re: Problems with question marks in operators (JDBC, ECPG, ...) |
Previous Message | Bruno Harbulot | 2015-05-19 18:44:37 | Re: Problems with question marks in operators (JDBC, ECPG, ...) |