Re: plperl security

Andrew Dunstan wrote:

>
>
> Tom Lane wrote:
>
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>
>>
>>> Currently we have this in plperl.c:
>>> "require Safe;"
>>> I am thinking of submitting a patch to replace this with "use Safe
>>> 2.09;" to enforce use of a version without the known vulnerability.
>>>
>>
>>
>> This would break both plperl and plperlu on older Perls. Please see
>> if you can avoid breaking plperlu.
>>
>> For that matter, does plperl.c really cope properly with a failure in
>> this code at all? I sure don't see anything that looks like error
>> handling in plperl_init_interp().
>>
>>
>>
>>
>
> I will look at it. It will probably require some non-trivial rework.
>
> I do agree that we should not break more old stuff than is necessary.
>
>

The thing is that unlike TCL we have one interpreter for both trusted
and untrusted cases.

My thinking is to factor out all the code that only applies to trusted
cases from the interpreter init code, and only call it if we try to
compile a trusted function and it hasn't been run yet. Does that seem
reasonable?

The code in question would be:

always in interp init:

SPI::bootstrap(); use vars qw(%_SHARED);
sub ::mkunsafefunc {return eval(qq[ sub { $_[0] $_[1] } ]); }

only if needed for trusted cases:

use Safe 2.09;
use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');

$PLContainer->permit_only(':default');$PLContainer->permit(':base_math');
$PLContainer->share(qw[&elog &spi_exec_query &DEBUG &LOG &INFO
&NOTICE &WARNING &ERROR %SHARED ]);
sub ::mksafefunc { return $PLContainer->reval(qq[sub { $_[0]
$_[1]}]); }

Still looking at robustness issues.

cheers

andrew