On Tue, May 19, 2015 at 2:46 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-05-19 14:41:06 -0400, Robert Haas wrote:
>> On Tue, May 19, 2015 at 12:29 PM, Andres Freund <andres@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?
Yes, something like that. I'm not sure if we'd want to reuse the
existing SESSION AUTHORIZATION concept or create something new, but
either way the idea would be that the pooler would send a
PoolerSetAuthorization message which could only be undone by another
such message.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company