Re: allowing for control over SET ROLE

On Thu, Nov 17, 2022 at 04:24:24PM -0800, Jeff Davis wrote:
> On Thu, 2022-11-17 at 16:52 -0500, Robert Haas wrote:
> > But I think the bigger reason is that, in my opinion, this proposal is
> > more generally useful, because it takes no position on why you wish to
> > disallow SET ROLE. You can just disallow it in some cases and allow it in
> > others, and that's fine.

In this commit 3d14e17, the documentation takes the above "no position". The
implementation does not, in that WITH SET FALSE has undocumented ability to
block ALTER ... OWNER TO, not just SET ROLE. Leaving that undocumented feels
weird to me, but documenting it would take the position that WITH SET FALSE is
relevant to the security objective of preventing object creation like the
example in the original post of this thread. How do you weigh those
documentation trade-offs?

> I agree that the it's more flexible in the sense that it does what it
> does, and administrators can use it if it's useful for them. That means
> we don't need to understand the actual goals as well; but it also means
> that it's harder to determine the consequences if we tweak the behavior
> (or any related behavior) later.

I have similar concerns. For the original post's security objective, the role
must also own no objects of certain types. Otherwise, WITH SET FALSE members
can use operations like CREATE OR REPLACE FUNCTION or CREATE INDEX to escalate
to full role privileges:

create user unpriv;
grant pg_maintain to unpriv with set false;
create schema maint authorization pg_maintain
create table t (c int);
create or replace function maint.f() returns int language sql as 'select 1';
alter function maint.f() owner to pg_maintain;
set session authorization unpriv;
create or replace function maint.f() returns int language sql security definer as 'select 1';
create index on maint.t(c);