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.
To me, this seems more accidental than the natural fallout of good design.
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
