On Wed, Jan 11, 2023 at 10:16 AM Noah Misch <noah@leadboat.com> wrote:
> 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
Ah, thanks.
> 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 think so, too. Note the wording of the error message in check_can_set_role().
> 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.)
I spent a while on this. The attached is as well I was able to figure
out how to do. What do you think?
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com