Re: RFC: Non-user-resettable SET SESSION AUTHORISATION

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
Дата
Msg-id CA+TgmoZESkjpaLna-2zWwUCtttYYbiGnB9Z0MEcV6NQLQM9xfA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RFC: Non-user-resettable SET SESSION AUTHORISATION  (Andres Freund <andres@anarazel.de>)
Ответы Re: RFC: Non-user-resettable SET SESSION AUTHORISATION  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: a few thoughts on the schedule
Следующее
От: Bruno Harbulot
Дата:
Сообщение: Re: Problems with question marks in operators (JDBC, ECPG, ...)