Re: Extension ownership and misuse of SET ROLE/SET SESSION AUTHORIZATION

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