Re: REASSIGN OWNED vs ALTER TABLE OWNER TO permission inconsistencies

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, adamwolk(at)microsoft(dot)com
Subject: Re: REASSIGN OWNED vs ALTER TABLE OWNER TO permission inconsistencies
Date: 2023-02-17 02:24:45
Message-ID: Y+7lbQhB9URTj7vU@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Wed, Feb 15, 2023 at 9:01 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > I'm not really a fan of just dropping the CREATE check. If we go with
> > "recipient needs CREATE rights" then at least without superuser
> > intervention and excluding cases where REVOKE's or such are happening,
> > we should be able to see that only objects where the owners of those
> > objects have CREATE rights exist in the system. If we drop the CREATE
> > check entirely then clearly any user who happens to have access to
> > multiple roles can arrange to have objects owned by any of their roles
> > in any schema or database they please without any consideration for what
> > the owner of the parent object's wishes are.
>
> That's true, and it is a downside of dropping to CREATE check, but
> it's also a bit hard to believe that anyone's really getting a lot of
> value out of the current inconsistent checks.

I agree that we should be consistent about these checks. I'm just more
inclined to have that consistent result include the CREATE check than
have it be dropped. Not sure that it's a huge thing but being able to
control what set of owner roles are allowed to have objects in a given
schema seems useful and was certainly the intent, as I recall anyhow.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonah H. Harris 2023-02-17 02:34:18 Re: Reducing System Allocator Thrashing of ExecutorState to Alleviate FDW-related Performance Degradations
Previous Message Thomas Munro 2023-02-17 02:22:39 Re: Dead code in ps_status.c