On Wed, Feb 15, 2023 at 9:01 AM Stephen Frost <sfr...@snowman.net> wrote: > I don't think I really agree that "because a superuser can arrange for > it to not be valid" that it follows that requiring the recipient to have > CREATE permission on the parent object doesn't make sense. Surely for > any of these scenarios, whatever rule we come up with (assuming we have > any rule at all...) a superuser could arrange to make that rule no > longer consistent.
Well .... yes and no. The superuser can always hack things by modifying the system catalogs, but we have plenty of integrity constraints that a superuser can't just casually violate because they feel like it. For example, a superuser is no more able to revoke privileges without revoking the privileges that depend upon them than anyone else. > I'm not really a fan of just dropping the CREATE check. If we go with > "recipient needs CREATE rights" then at least without superuser > intervention and excluding cases where REVOKE's or such are happening, > we should be able to see that only objects where the owners of those > objects have CREATE rights exist in the system. If we drop the CREATE > check entirely then clearly any user who happens to have access to > multiple roles can arrange to have objects owned by any of their roles > in any schema or database they please without any consideration for what > the owner of the parent object's wishes are. That's true, and it is a downside of dropping to CREATE check, but it's also a bit hard to believe that anyone's really getting a lot of value out of the current inconsistent checks. -- Robert Haas EDB: http://www.enterprisedb.com