On Thu, Feb 13, 2020 at 5:55 PM Tom Lane <tgl@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
