Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
От | Andres Freund |
---|---|
Тема | Re: RFC: Non-user-resettable SET SESSION AUTHORISATION |
Дата | |
Msg-id | 20150519184615.GF14931@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: RFC: Non-user-resettable SET SESSION AUTHORISATION (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
Re: RFC: Non-user-resettable SET SESSION AUTHORISATION |
Список | 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@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? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: