Now that we're just about there on the patch to invent trusted
extensions [1], I'd like to start a discussion about whether to mark
anything besides the trusted PLs as trusted. I think generally
we ought to mark contrib modules as trusted if it's sane to do so;
there's not much point in handing people plperl (even sandboxed)
but not, say, hstore. I trawled through what's in contrib today
and broke things down like this:
Certainly NO, as these allow external or low-level access:
adminpack
dblink
file_fdw
postgres_fdw
pageinspect
pg_buffercache
pg_freespacemap
pg_visibility
pgstattuple
Probably NO, if only because you'd need additional privileges
to use these anyway:
amcheck
dict_xsyn
hstore_plperlu
hstore_plpython2u
hstore_plpython3u
hstore_plpythonu
jsonb_plperlu
jsonb_plpython2u
jsonb_plpython3u
jsonb_plpythonu
ltree_plpython2u
ltree_plpython3u
ltree_plpythonu
pg_prewarm
pg_stat_statements
Definitely candidates to mark trusted:
citext
cube
dict_int (unlike dict_xsyn, this needs no external file)
earthdistance (marginal usefulness though)
fuzzystrmatch
hstore
hstore_plperl
intagg (marginal usefulness though)
intarray
isn
jsonb_plperl
lo
ltree
pg_trgm
pgcrypto
seg
tablefunc
tcn
tsm_system_rows
tsm_system_time
unaccent (needs external file, but the default one is useful)
uuid-ossp
Not sure what I think about these:
bloom (are these useful in production?)
btree_gin
btree_gist
pgrowlocks (seems safe, but are there security issues?)
spi/autoinc (I doubt that these four are production grade)
spi/insert_username
spi/moddatetime
spi/refint
sslinfo (seems safe, but are there security issues?)
xml2 (nominally safe, but deprecated, and libxml2
has been a fertile source of security issues)
Any opinions about these, particularly the on-the-edge cases?
Also, how should we document this, if we do it? Add a boilerplate
sentence to each module's description about whether it is trusted
or not? Put a table up at the front of Appendxix F? Both?
I'm happy to go make this happen, once we have consensus on what
should happen.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/5889.1566415762%40sss.pgh.pa.us
