On 18 May 2015 at 12:33, Alvaro Herrera <alvhe...@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: > > > >=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= <jltal...@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/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
