Re: allowing for control over SET ROLE

On Tue, Jan 10, 2023 at 11:06:52AM -0500, Robert Haas wrote:
> On Sat, Jan 7, 2023 at 12:00 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > The docs are silent on the SET / OWNER TO connection. Hence,
>
> Reviewing the documentation again today, I realized that the
> documentation describes the rules for changing the ownership of an
> object in a whole bunch of places which this patch failed to update.
> Here's a patch to update all of the places I found.

A "git grep 'direct or indirect mem'" found a few more:

doc/src/sgml/ref/alter_collation.sgml:42: To alter the owner, you must also be a direct or indirect member of the new
doc/src/sgml/ref/create_database.sgml:92: role, you must be a direct or indirect member of that role,
doc/src/sgml/ref/create_schema.sgml:92: owned by another role, you must be a direct or indirect member of

I wondered if the new recurring phrase "must be able to SET ROLE" should be
more specific, e.g. one of "must have
{permission,authorization,authority,right} to SET ROLE". But then I stopped
wondering and figured "be able to" is sufficient.

> I suspect that these changes will mean that we don't also need to
> adjust the discussion of the SET option itself, but let me know what
> you think.

I still think docs for the SET option itself should give a sense of the
diversity of things it's intended to control. It could be simple. A bunch of
the sites you're modifying are near text like "These restrictions enforce that
altering the owner doesn't do anything you couldn't do by dropping and
recreating the aggregate function." Perhaps the main SET doc could say
something about how it restricts other things that would yield equivalent
outcomes. (Incidentally, DROP is another case of something one likely doesn't
want the WITH SET FALSE member using. I think that reinforces a point I wrote
upthread. To achieve the original post's security objective, the role must
own no objects whatsoever.)