Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
От | Alvaro Herrera |
---|---|
Тема | Re: RFC: Non-user-resettable SET SESSION AUTHORISATION |
Дата | |
Msg-id | 20150518163325.GO2523@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: RFC: Non-user-resettable SET SESSION AUTHORISATION (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
Re: RFC: Non-user-resettable SET SESSION AUTHORISATION |
Список | pgsql-hackers |
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. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: