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.
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 |