Re: Bug introduced by recent ALTER OWNER permissions check change

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > I don't like this approach to solving the problem. I would rather see
> > the check modified to allow the ownership change provided:
>
> > the user issueing the command has access to destination role
> > AND
> > (
> > the destination role can create the table
> > OR the user issuing the command has owner rights on the schema/db
> > )
> > etc
>
> I don't think so --- this would allow unprivileged users to use ALTER
> OWNER to arrive at states they could not arrive at otherwise; which
> destroys the entire argument that non-superuser ALTER OWNER is not a
> security risk. Shall we reverse out the patch and require you to
> justify it from scratch?

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. So, such
unprivileged users (which yet are owners of the schema in question, one
of the requirements above) could arrive at that state regardless.

> Superusers should be allowed to do whatever they want, but that doesn't
> mean that we should weaken the rules applied to ordinary users.

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

Thanks,

Stephen