Tom Lane <tgl@sss.pgh.pa.us> writes:
> This would be a serious security problem if it weren't for the fact that
> nearly all internal-accepting functions in the backend are also marked
> STRICT, and so they won't get called in this type of scenario. A query
> to pg_proc shows that the only ones that aren't strict are
>
> regression=# select oid::regprocedure from pg_proc where 'internal'::regtype = any (proargtypes) and not
proisstrict;
> oid
> ----------------------------------------
> array_agg_transfn(internal,anyelement)
> array_agg_finalfn(internal)
> domain_recv(internal,oid,integer)
> (3 rows)
>
> The first two are new in 8.4, and the third has adequate defenses
> already. So we don't have a security hole in any released version
> right now.
How about contrib/ ? I have this in my test 8.3.7 database:
seb=> select oid::regprocedure from pg_proc where 'internal'::regtype = any (proargtypes) and not proisstrict;
oid
---------------------------------------------------------------domain_recv(internal,oid,integer)utils_pg.gtrgm_same(utils_pg.gtrgm,utils_pg.gtrgm,internal)utils_pg.gin_extract_trgm(text,internal)utils_pg.gin_extract_trgm(text,internal,internal)utils_pg.gin_trgm_consistent(internal,internal,text)utils_pg.ghstore_compress(internal)utils_pg.ghstore_decompress(internal)utils_pg.ghstore_picksplit(internal,internal)utils_pg.ghstore_union(internal,internal)utils_pg.ghstore_same(internal,internal,internal)utils_pg.ghstore_consistent(internal,internal,integer)utils_pg.gin_extract_hstore(internal,internal)utils_pg.gin_extract_hstore_query(internal,internal,smallint)utils_pg.gin_consistent_hstore(internal,smallint,internal)utils_pg.gtrgm_consistent(utils_pg.gtrgm,internal,integer)utils_pg.gtrgm_compress(internal)utils_pg.gtrgm_decompress(internal)utils_pg.gtrgm_picksplit(internal,internal)utils_pg.gtrgm_union(bytea,internal)
(19 rows)
--
Sergey Burladyan
