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

On Mon, May 18, 2015 at 12:33 PM, 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.

That seems like a kludge to me.  If the cookie leaks out somhow, which
it will, then it'll be insecure.  I think the way to do this is with a
protocol extension that poolers can enable on request.  Then they can
just refuse to forward any "reset authorization" packets they get from
their client.  There's no backward-compatibility break because the
pooler can know, from the server version, whether the server is new
enough to support the new protocol messages.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company