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

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
Дата
Msg-id CANP8+jK0Vna-Xc48svjYnORU=7Kcp87S6RSsNCWZxqsxXBMmSw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RFC: Non-user-resettable SET SESSION AUTHORISATION  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: RFC: Non-user-resettable SET SESSION AUTHORISATION  (José Luis Tallón <jltallon@adv-solutions.net>)
Re: RFC: Non-user-resettable SET SESSION AUTHORISATION  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 18 May 2015 at 12:33, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Bruce Momjian wrote:
> On Sun, May 17, 2015 at 09:31:47PM +0200, José Luis Tallón wrote:
> > On 05/17/2015 07:39 PM, Tom Lane wrote:
> > >José Luis Tallón <jltallon@adv-solutions.net> writes:
> > >>On the other hand, ISTM that what we all intend to achieve is some
> > >>Postgres equivalent of the SUID bit... so why not just do something
> > >>equivalent?
> > >>-------
> > >>      LOGIN    -- as user with the appropriate role membership / privilege?
> > >>      ...
> > >>      SET ROLE / SET SESSION AUTHORIZATION WITH COOKIE / IMPERSONATE
> > >>      ... do whatever ...    -- unprivileged user can NOT do the
> > >>"impersonate" thing
> > >>      DISCARD ALL    -- implicitly restore previous authz
> > >>-------
> > >Oh?  What stops the unprivileged user from doing DISCARD ALL?
> >
> > Indeed. The pooler would need to block this.
> > Or we would need to invent another (this time, privileged) verb in
> > order to restore authz.
>
> What if you put the SQL in a function then call the function?  I don't
> see how the pooler could block this.

I think the idea of having SET SESSION AUTH pass a cookie, and only let
RESET SESSION AUTH work when the same cookie is supplied, is pretty
reasonable.

As long as the cookie is randomly generated for each use, then I don't see a practical problem with that approach.

Protocol level solution means we have to wait 1.5 years before anybody can begin using that. I'm also dubious that a small hole in the protocol arrangements could slam that door shut because we couldn't easily backpatch.

Having an in-core pooler would be just wonderful because then we could more easily trust it and we wouldn't need to worry. 

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Предыдущее
От: Mike Blackwell
Дата:
Сообщение: Re: Problems with question marks in operators (JDBC, ECPG, ...)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Problems with question marks in operators (JDBC, ECPG, ...)