From: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> |
---|---|
To: | Alex Hunsaker <badalex(at)gmail(dot)com> |
Cc: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-bugs(at)postgresql(dot)org, "David E(dot) Wheeler" <david(dot)wheeler(at)pgexperts(dot)com>, Rafael Garcia-Suarez <rgs(at)consttype(dot)org> |
Subject: | Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0) |
Date: | 2010-02-23 22:54:45 |
Message-ID: | 20100223225445.GU1018@timac.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2010-02-24 01:48:29 | RETURNS TABLE returns NULL set when called by another RETURNS TABLE |
Previous Message | Simon Ng | 2010-02-23 22:43:53 | BUG #5344: pg_restore some foreign keys missing |