Re: REASSIGN OWNED vs ALTER TABLE OWNER TO permission inconsistencies

On Wed, Feb 15, 2023 at 9:01 AM Stephen Frost <sfrost(at)snowman(dot)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