On Mon, May 18, 2015 at 12:33 PM, Alvaro Herrera <alvhe...@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: >> > >=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= <jltal...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
