Re: RFC: Non-user-resettable SET SESSION AUTHORISATION - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
Date
Msg-id 20150518154132.GC9458@momjian.us
Whole thread Raw
In response to Re: RFC: Non-user-resettable SET SESSION AUTHORISATION  (José Luis Tallón <jltallon@adv-solutions.net>)
Responses Re: RFC: Non-user-resettable SET SESSION AUTHORISATION  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
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.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: 9.5 open items
Next
From: Jim Nasby
Date:
Subject: Re: Making the regression tests halt to attach a debugger