On Thu, Feb 13, 2020 at 5:55 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > (1) In the backend, allow SET ROLE to succeed if either the session > userid or the current userid is a member of the desired role. This > would mean that, given the use-case for --role that you are logging > into an account that can "SET ROLE postgres", it'd work to do > > SET ROLE postgres; > SET ROLE anybody; > ... create an object to be owned by anybody > SET ROLE postgres; > SET ROLE somebodyelse; > ... create an object to be owned by somebodyelse > SET ROLE postgres; > ... lather rinse repeat
Honestly, the fact that this would work where a direct SET ROLE would fail seems horribly counterintuitive. > Having said that ... I can't find the discussion right now, but > I recall Peter or Stephen complaining recently about how SET ROLE > and SET SESSION AUTHORIZATION allow more than the SQL spec says > they should. Do we want to make successful restores dependent > on an even-looser definition of SET ROLE? If not, how might we > handle this problem without assuming non-SQL semantics? I don't know how to solve this problem, but I think loosening the requirements for 'SET ROLE' is something where a lot of caution is warranted. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
