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

From Robert Haas
Subject Re: Removing pg_pltemplate and creating "trustable" extensions
Date
Msg-id CA+Tgmobk+ihJ498JF_XD=aLryTAujmmA5qn86qRUdBvd3g-hog@mail.gmail.com
Whole thread Raw
In response to Re: Removing pg_pltemplate and creating "trustable" extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Removing pg_pltemplate and creating "trustable" extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Removing pg_pltemplate and creating "trustable" extensions  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Thu, Jan 9, 2020 at 1:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > Again, as I said upthread, Tom had the exact feature about which I am
> > talking in the first version of the patch. That is a strong argument
> > in favor of it being practical. It's also a pretty good argument that
> > it is at least potentially useful, because Tom doesn't usually do
> > useless things for no reason.
>
> To try to clarify that a bit: I think there is certainly some value
> in allowing superusers to control which extensions could be installed
> by non-superusers, further restricting what we may think is trustworthy.

Cool.

> However, I felt at the time that my GUC-based implementation of that
> was ugly, and then Peter raised some concrete points against it,
> so I took it out.  I don't want to put it back in the same form.
> I think we could leave designing a replacement for later, because it's
> pretty optional, especially if we aren't aggressive about promoting
> contrib modules to "trusted" status.

Agreed.

> I don't agree that the lack of
> such a feature is a reason not to commit what I've got.

I said the same in
http://postgr.es/m/CA+TgmoYgwgS_RnMOooczZCgrZFqtfngshAq2Gu7LM5SKxrf_xQ@mail.gmail.com
- penultimate paragraph, last sentence.

> In any case, AFAICT most of the heat-vs-light in this thread has not
> been about which extensions are trustworthy, but about which users
> should be allowed to install extensions, which seems like a totally
> independent discussion.

I agree it's independent. It wasn't really the main point of what *I*
was trying to talk about, but the heat-vs-light problem seems to have
totally obscured what I *was* trying to talk about.

> And controlling that is also a feature that
> we don't have today, so I'd rather get a minimal feature committed
> for v13 and then later consider whether we need more functionality.
>
> The idea of a DB-level INSTALL privilege addresses the second
> point not the first, unless I'm totally misunderstanding it.  As
> I said before, I'm not terribly comfortable with handing control
> of that over to non-superuser DB owners, and I sure don't see why
> doing so should be a required part of the minimal feature.

So, if I understand correctly, the patch you are proposing to commit
has a new system role, and if you've got that system role, then you
can install extensions. I thought that part of the earlier debate was
whether DB owners should also be able to install trusted extensions
even without that role, and I thought it would be cleaner if the
answer was "no," because then the superuser could decide whether to
grant that role or not in particular cases. But I'm not clear whether
you agreed with that, what Stephen thought about it, or whether that's
still what you are proposing to commit.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: our checks for read-only queries are not great
Next
From: Tom Lane
Date:
Subject: Re: our checks for read-only queries are not great