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

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> 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.

I'm arguing for the position that superusers/admins have the ability to
control which extensions exist on the filesystem, and that plus the
'trusted' marking is sufficient flexibility.

> > 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.

Also agreed- which is why I figured we weren't really discussing that
any more.

> > 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.

I also agree that we don't need the "who can install what extension"
flexibility that the original GUC-based approach contemplated, but
that's because I don't think we are likely to ever need it.  If we do
and someone comes up with a good design for it, that'd be fine too.

> > 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.

I'm entirely confused about what you were trying to talk about then.

Most of the back-and-forth, as I saw it anyway, were points being raised
to say "we can't let the right of installing extensions be allowed to DB
owners", which I don't agree with and which I've yet to see an actual
justification for beyond "well, we think it should require some explicit
superuser privilege-granting, beyond the granting that the superuser
does when they create a database owned by a given user."

> > 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.

I do *not* agree with having a default role for this, at all.  This
looks just like the right to CREATE tables or functions inside a schema,
except with a DB-level object (an extension) instead of a schema-level
object, and that is the purview of the DB owner.

The arguments raised about $SCARYEXTENSION and security concerns make a
lot of sense- I agree that those are things we should discuss and make
sure that allowing a DB owner this privilege won't pave a way for them
to get superuser access, but, imv anyway, we discussed those and didn't
actually come up with any cases where it'd be an issue, in part thanks
to Tom's design where the objects end up owned by the bootstrap
superuser except in specific cases.

So I'm at a loss for why there is this insistence on a default role and
a superuser-explicit-granting based approach that goes beyond "is it
installed on the filesystem?" and "is it marked as trusted?".

Thanks,

Stephen