Re: Bug introduced by recent ALTER OWNER permissions check change

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Considering I am superuser, it should darn well allow this.

Agreed.

> The problem of course is the test that u1 would have the rights to
> create t1 in s1, which he doesn't. I think we have to skip that
> test if superuser. As long as we need an explicit test on
> superuserness, we may as well skip *all* the added code.
>
> Comments?

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

This would solve the superuser() issue and would allow owners of schemas
to have an object in their schema owned by a role (which presumably
generally has less/limited access) which doesn't (and probably
shouldn't, ever, really) have create access on that schema.

A fairly common setup I have is to create roles with very limited access
(certainly not create access on a schema) and then grant only the access
they need. In some cases, those roles do need ownership-level
permissions (unfortunately) on tables so that they can do truncates,
vacuums, etc, since our permissions system isn't granular enough to give
them just that access w/o ownership.

The cases where the limited access role gets ownership of a table isn't
very common (I try to avoid it) but it does happen from time to time.
Of course, currently I just use superuser to make such adjustments, but
being able to do it as my regular user would be nice, imv.

Thanks,

Stephen