| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | José Luis Tallón <jltallon(at)adv-solutions(dot)net> |
| 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 17:39:14 |
| Message-ID: | 1833.1431884354@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
=?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?
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | José Luis Tallón | 2015-05-17 19:31:47 | Re: RFC: Non-user-resettable SET SESSION AUTHORISATION |
| Previous Message | José Luis Tallón | 2015-05-17 17:31:29 | Re: RFC: Non-user-resettable SET SESSION AUTHORISATION |