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 <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?
>
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