Marking some contrib modules as trusted extensions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Marking some contrib modules as trusted extensions
Date: 2020-01-29 19:41:16
Message-ID: 32315.1580326876@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2020-01-29 19:50:26 Re: Enabling B-Tree deduplication by default
Previous Message Mark Wong 2020-01-29 19:16:52 Re: [HACKERS] kqueue