Thanks a lot Tom and Andres. Can you please guide me what is the recommended steps?
On Wed, 15 Nov 2023 at 04:55, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Andres Freund <andres@xxxxxxxxxxx> writes:
> On 2023-11-14 17:40:02 -0500, Tom Lane wrote:
>> ... no, it should be for the user executing the ALTER to have permission.
> That check succeed - what fails is a check on the new owner of the table. See
> tablecmds.c ATExecChangeOwner:
> /* New owner must have CREATE privilege on namespace */
> aclresult = object_aclcheck(NamespaceRelationId, namespaceOid, newOwnerId,
> ACL_CREATE);
Oh! I was just thinking about the initial object-lookup check,
I'd forgotten about the one in the ALTER OWNER code itself.
Hm. The intent of that check is to ensure that the ALTER doesn't
produce a situation that the object-recipient user couldn't have
created by himself. But I wonder if that's too narrow-minded, and
we should craft a new rule that allows things dependent on only the
calling user's permissions. Maybe allow if either the calling user or
the recipient has CREATE on the schema? Or allow if calling user has
ownership on the schema (implying that he could temporarily GRANT the
necessary rights and then undo it)? Either of those would legitimize
what pg_dump wants to do.
This is getting way off-topic for pgsql-admin, btw.
regards, tom lane
