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

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Tue, Jan 7, 2020 at 7:32 PM Stephen Frost <sfrost@snowman.net> wrote:
> > You raised the point regarding postgres_fdw and a DB owner being able to
> > run 'create extension postgres_fdw;' and to then make network
> > connections, but that's proven to be invalid because, assuming we make
> > postgres_fdw trustable, we will surely make the FDW itself that's
> > created be owned by the bootstrap superuser and therefore the DB owner
> > *couldn't* create such network connections- at least, now without an
> > additional step being taken by a superuser.  Further, it's pretty clear
> > to everyone *why* that additional step has to be taken for postgres_fdw.

(guessing it was clear, but sorry for the typo above, 'now' should have
been 'not')

> To me, this seems more accidental than the natural fallout of good design.

I disagree that the privilege design for FDWs was accidental.  Perhaps
it was a mistake to automatically run the CREATE FDW as part of the
extension script, but that doesn't really change any of the argument I'm
making.

> > Why would a $SCARY_EXTENSION be marked as trusted?
>
> Well, again, my point in using postgres_fdw as an example was not that
> it should be untrusted, or that it should be trusted, but that
> different people might have different views about that question, and
> therefore configurability would be good. I believe the same thing
> applies in other cases. For me, this boils down to the view that the
> superuser can have arbitrary preferences about what C code they want
> to let users run, and they need not justify such views with reference
> to anything in particular. Some superuser can decide that they think
> hstore is great stuff but bloom is too experimental and isn is a pile
> of crap, and that all seems perfectly legitimate to me. And some other
> superuser can have a different view and that seems fine, too. I can't
> think of any reason why a particular installation should have to
> decide between certifying most of contrib and certifying none of it,
> with no intermediate options. I guess you see it differently.

What I see differently is that the purview of those decisions should be
that of the DB owner and not the superuser.  If the superuser really
wants to own those decisions, then they should be the DB owner too, and
then they can also control what schemas exist and who can use them, or
they can GRANT that right out only to whomever they trust with it, and
likewise could GRANT out this install-extension right out to whomever
they deem worthy.

As it relates to things in contrib that could be classified as 'a pile
of crap' or 'too experimental'- that's *our* failing, and one which we
should accept and address instead of punting on it.  In my recollection,
this is far from the first time someone's suggested that maybe we should
try to clean up contrib.  I don't accept that our reluctance to punt
things out of contrib that shouldn't be there is an acceptable argument
against using our existing GRANT system for this new right or sufficient
justification to use a default role instead.

Thanks,

Stephen