Re: Bug introduced by recent ALTER OWNER permissions check change

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> Does it really? I don't think so. If you have owner privileges on the
> schema you can grant create rights to the role, then either ALTER OWNER
> if the patch is kept or just change to the role, create table x as
> select * from y;, etc, and then revoke the create privileges.

Hmm, that would work, but it still leaves me itchy. If we allow this,
why not even further-removed schemes requiring several SET ROLEs?
For instance, you could argue that ALTER OWNER should be allowed to
anyone who can become the old object owner, even if their current role
doesn't include that privilege. (That is, the difference between
is_member and has_privs checks.) Or say that either the old or new
object owner can be owner of the containing schema. (Which would amount
to disregarding whether a schema owner has revoked his own CREATE
privilege, on the grounds that he could always choose to grant it to
himself again.) I'm really leery of going down this path without
significant use-cases in its favor.

> Having to special case superusers all over the place is an indication of
> poor design, imho.

Contorting the privilege rules to avoid special-casing superusers is
worse, imho. At least when you do "if (superuser())" you know you
aren't creating any holes that might be exploitable by non-superusers.

regards, tom lane