Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
