Disallow execution of SPI functions during plperl function compilation.
authorTom Lane <[email protected]>
Fri, 25 Feb 2022 22:40:21 +0000 (17:40 -0500)
committerTom Lane <[email protected]>
Fri, 25 Feb 2022 22:40:21 +0000 (17:40 -0500)
commit4936747c477270e133e622bf6d7a12fa246cf3a7
treea11b76d65ee0430dfe63053f33ff66b475117319
parentcebc54b90bda3ce43dc60faf216d2d149eebd3f3
Disallow execution of SPI functions during plperl function compilation.

Perl can be convinced to execute user-defined code during compilation
of a plperl function (or at least a plperlu function).  That's not
such a big problem as long as the activity is confined within the
Perl interpreter, and it's not clear we could do anything about that
anyway.  However, if such code tries to use plperl's SPI functions,
we have a bigger problem.  In the first place, those functions are
likely to crash because current_call_data->prodesc isn't set up yet.
In the second place, because it isn't set up, we lack critical info
such as whether the function is supposed to be read-only.  And in
the third place, this path allows code execution during function
validation, which is strongly discouraged because of the potential
for security exploits.  Hence, reject execution of the SPI functions
until compilation is finished.

While here, add check_spi_usage_allowed() calls to various functions
that hadn't gotten the memo about checking that.  I think that perhaps
plperl_sv_to_literal may have been intentionally omitted on the grounds
that it was safe at the time; but if so, the addition of transforms
functionality changed that.  The others are more recently added and
seem to be flat-out oversights.

Per report from Mark Murawski.  Back-patch to all supported branches.

Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f083d2@intellasoft.net
src/pl/plperl/plperl.c