Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)

On Tue, Feb 23, 2010 at 02:59:05PM -0700, Alex Hunsaker wrote:
> On Tue, Feb 23, 2010 at 14:29, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> wrote:
> > David Wheeler has discovered a new PL/Perl failure when using Safe 2.2x.
>
> *sigh*.
>
> Thanks for all the testing David! And of course many thanks to Tim
> for all the hours of analysis and hard work!
>
> > That'll fix the immediate problem for all PostgreSQL versions.
> > Security will be no better or worse that it was before Safe 2.20.
> > The old sort { } bug (where $a & $b) don't work will return but
> > that seems a very small price to pay for a simple fix.
>
> +1. Although I think I might be in favor of just ripping it out all
> together. There are a couple of goofy things about the current
> behavior anyway. Notably if you are not using a threaded build you
> never get the extra protection.

Yes, that needs resolving. Thanks for the reminder.

> At the time it was really just a fix
> for the namespace issues. I do agree the increased security is
> nice... But that was not the primary goal :)

We'll discuss the issues and API option for Safe on the perl5-porters
mailing list.

> > I'd like to see PostgreSQL re-enable use of the wrapped subroutines
> > in the future but it'll require some development effort.
>
> I would to.
>
> > The plperl
> > entry points will need to detect if Safe is 'in effect' and locally undo
> > it.  There's some prior art in http://search.cpan.org/perldoc?Safe::Hole
> > that might be useful.
>
> Yick... There must be a better way?

Doesn't seem too icky. Basically plperl would need to save the values of
PL_defstash, PL_incgv and PL_op_mask when a plperl interpreter is
initialized. And then local()'ly restore them in the plperl entry points.
Should only be a few lines of code - in theory :)

Tim.