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

On 18 May 2015 at 12:33, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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?= <jltallon(at)adv-solutions(dot)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