On Tue, Jan 7, 2020 at 7:32 PM Stephen Frost <sfr...@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
