Re: Bug introduced by recent ALTER OWNER permissions check change

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.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?

I'm not entirely sure I follow...  In the 'inherit_role' case, which is
what I'm thinking about anyway, you have all the permissions which are
granted to any role you're in.  One of those permissions is to create
objects owned by that role.  Allowing users to 'alter owner', while
useful in its own right, also makes up for the inability to create an
object owned by a role you're in directly.

> 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.)

I don't see how, having only the rights of the old object owner, you
could recreate the object as owned by another role which you're in,
unless you also had ownership permissions on the schema in question.

This isn't a case where several SET ROLEs would be necessary, this
appears to be a case which, regardless of how many SET ROLEs are done,
the user attempting to change the ownership wouldn't be able to.  As
such, I see it as something distinct and seperate from my argument.

Perhaps I've misunderstood though.

> 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.

Well, hang on, this case is already reasonably covered, imv:
You still have to be able to become the 'new owner' role, therefore you
have the permissions granted by that role, and those permissions may
provide the current user with 'owner' status on the schema.

I don't see this case as different from the original situation under
discussion.  The requirements being:

You must have ownership rights on the object before the change.
AND
You must have ownership rights on the object after the change.
AND
(
The new owner must have CREATE rights on the schema.
OR
You must have ownership rights on the schema.
)

The ownership rights on the schema being granted by the old role or the
new role, or some other role, or directly to the user, is unimportant.

> > 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.

Instead you're requiring more and more users to be superusers in order
to get things done, increasing the chances of a superuser-level
compromise.  Having "if (superuser())" in alot of places encourages use
of superuser-level accounts which I think should generally be
discouraged in favor of more granular permissions in the system to help
mitigate the risk of a given account being compromised.
Thanks,
    Stephen