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

From: José Luis Tallón <jltallon(at)adv-solutions(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
Date: 2015-05-17 19:31:47
Message-ID: 5558ECA3.1030605@adv-solutions.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

> I think if we have something like this, it has to be non-resettable
> period: you can't get back the old session ID except by reconnecting
> and re-authorizing. Otherwise there's just too much risk of security
> holes.

Yes.
Thank you for your feedback, Tom.

/ J.L.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-05-17 20:23:08 Re: WALWriteLock contention
Previous Message Tom Lane 2015-05-17 17:39:14 Re: RFC: Non-user-resettable SET SESSION AUTHORISATION