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+TgmoYKLetGg7wRREYUQ=M+gSjYfZBb2AV6ad5C8aurJFqPjA@mail.gmail.com
Whole thread Raw
In response to Re: Removing pg_pltemplate and creating "trustable" extensions  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Removing pg_pltemplate and creating "trustable" extensions  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Wed, Jan 8, 2020 at 6:09 PM Stephen Frost <sfrost@snowman.net> wrote:
> > To me, this seems more accidental than the natural fallout of good design.
>
> I disagree that the privilege design for FDWs was accidental.

That seems like a stronger statement than the one I made...

> What I see differently is that the purview of those decisions should be
> that of the DB owner and not the superuser.

Yeah, I don't agree with that at all. If I'm a hosting provider, I
want to tell my customers what they're allowed to run and what they're
not allowed to run, but I don't want them to have to call me when they
want to run an extension I've decided is OK.

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

I don't think changing what's in contrib helps much. Even if we rm
-rf'd it, there's the same problem with out-of-core extensions. Joe
Extensionman may think his extension ought to be trusted, and package
it as such, but Paula Skepticaldba is entitled to think Joe's view of
the security risks originating from his code is overly rosy.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: src/test/recovery regression failure on bionic
Next
From: Amit Kapila
Date:
Subject: Re: logical decoding : exceeded maxAllocatedDescs for .spill files