Re: Removing pg_pltemplate and creating "trustable" extensions - Mailing list pgsql-hackers

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> The patch as I'm proposing it has nothing to do with "CREATE" rights.
> >> You're attacking something different from what I actually want to do.
>
> > Yes, as an aside, I'm argueing that we should split up the general
> > CREATE privileges, but I also said that's not required for this.
>
> So how do we move this forward?  I really don't want this patch to be
> blocked by what's fundamentally a side point about permissions.
>
> The minimum committable patch seems like it would just grant the
> "can install trusted extensions" ability to DB owners, full stop.

If you're alright with making it something a DB owner can do, what is
the issue with making it part of the CREATE right on the database?  That
doesn't require any additional permission bits, in a default setup
doesn't change who is able to create extensions (in either your proposal
or mine, it's the DB owner), and in either proposal means that people
who couldn't create extensions with PG12 will be able to create them in
PG13.

We've added other things to the DB-level CREATE rights rather recently
too, so it's not like we've historically avoided that.

The argument you presented previously against that idea was because it
would mean the DB owner would still be able to exercise that right,
which is what you're now proposing anyway and which I was always
advocating for and wasn't trying to say wouldn't be the case with that
approach.

So I'm at a loss for what the actual argument is against making it part
of DB-level CREATE.

> This is small, it's exactly the same as our historical behavior for
> trusted PLs, and it's upward compatible with either of two possible
> future extensions:
>
> * adding a predefined role (which'd let superusers give out the install
> privilege, in addition to DB owners having it)

Uh, just to be clear, even with your approach, a DB owner could 'GRANT'
the necessary right for another user to install extensions by simply
GRANT'ing their own role to that user.  Obviously, that conveys other
privileges with it, but we have that problem at any level as long as we
constrain ourselves to a single set of 32 bits for representing
privileges.  I see it as being manifestly better to lump it in with the
DB-level CREATE privilege though.

> * converting DB owners' hard-wired privilege to a grantable privilege
> (which'd let DB owners give out the install privilege, if the privilege
> is attached to the DBs themselves; but maybe there's some other way?)

In either of these proposals, we could split up the bounded-together
privileges down the road, and, sure, there might be more than one way to
do that, but I really don't want to go down a road where every privilege
ends up being split up into a seperate default-role (or predefined role
or whatever we want to call those things today).

> Given the lack of consensus about either of those being what we want,
> it doesn't seem like we're going to come to an agreement in a
> reasonable timeframe on a patch that includes either.  So I'd like
> to get this done and move on to the next problem (ie, what is it
> we're actually going to do about the python 2/3 mess).

I get that you want to push forward with making this part of the DB
owner, and I said up-thread that I'd be able to live with that, but I
still don't understand what the argument is against making it part of
CREATE instead.

Thanks,

Stephen