On Fri, Jan 27, 2017 at 3:42 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> Normally, when changing the owner of an object, we check (among other
> things) that the new owner has the same privileges that would be needed
> to create the object from scratch. For for example, when changing the
> owner of a type, the new owner needs to have CREATE privilege on the
> containing schema. Or when changing the owner of a foreign server, the
> new owner needs to have USAGE privilege on the foreign-data wrapper.
>
> The exception is that when changing the owner of a schema or database,
> we check CREATE privilege on the database of the *current* user. There
> is even a comment about it in the code:
>
> * NOTE: This is different from other alter-owner checks in that the
> * current user is checked for create privileges instead of the
> * destination owner. This is consistent with the CREATE case for
> * schemas.
>
> I don't understand the rationale for this or what rationale that last
> sentence is apparently trying to give.
>
> I'm trying to extrapolate whatever rule this is to new object types, if
> appropriate.
This seems to have been introduced by
aa1110624c08298393dfce996f7b21809d98d3fd, written by Stephen Frost and
committed by Tom Lane in 2005, so maybe one of them remembers what the
motivation was. But off-hand I'd say it doesn't look very consistent.
If renaming a type requires (1) owning it, (2) being able to become
the new owner, and (3) that the new owner have permission to create a
type in that namespace, then why not have the check for schemas be
that (1) you must own it, (2) you must be able to become the new
owner, and (3) the new owner has permission to create that schema in
that database? But instead, renaming a schema just requires (1)
owning it and (2) permission for the current user to create schemas in
the current database. Like you, I can't piece together the rationale
for that apparent inconsistency from the comments.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company