Skip site navigation (1) Skip section navigation (2)

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

From: Alex Hunsaker <badalex(at)gmail(dot)com>
To: "David E(dot) Wheeler" <david(dot)wheeler(at)pgexperts(dot)com>
Cc: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
Date: 2010-02-25 19:08:42
Message-ID: 34d269d41002251108v297b0460pde29265552eb9714@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugs
On Thu, Feb 25, 2010 at 11:04, David E. Wheeler
<david(dot)wheeler(at)pgexperts(dot)com> wrote:
> There seem to be no good answers here.

Yeah, Here is the thing I don't think we can fix 'safe' or even patch
perl to get recursive calls to work.  Maybe Tim sees a way?  We can
work around it in 9.0 with plperl.on_init.  But breaking the back
branches makes it a non-starter.

Basically the problem as I see it is:
1) we call a plperl function which makes perl safe by denying certain
perl operations such as eval.
2) now that the interpreter is in that context, we try to compile a
new sub (using eval) and it fails.

I just don't see a way to make it work without making Safe useless.
For instance we could import the function that compiles the perl sub
into the safe.  But then anyone could call it and eval in random code.

Maybe Tim has something up his sleeve? (That does not require plperl.on_init?)

Here are the options I see:
1) revert safe to pre 2.2x behavior breaking sort {}, but fixing this
issue.  There would be a new function or a way to opt-in to the new
2.2x secure behavior (which would also fix sort, but this issue would
remain). (Tim's favored ATM)
[ breaks sort ]

2) patch perl to fix the sort {} issue (last I looked it would be
quite invasive and I think I would have a hard time getting it into
blead let alone 5.10.2 and 5.8.10), this issue would still be broken
[ still need to revert safe ]

3) patch postgres to fix the recursive issue (What I'm leaning towards)
[ fixes both issues ]

4) patch postgres to fix the *a, *b issue
[ still need to revert safe ]

5) make safe default import *a, *b to fix sort {} (rejected in the past)
[ still need to revert safe]

6) we might be able to do something in Safe to work around this... I
have an idea or two but I don't think they will pan out. (Basically it
used to work because we were only in the Safe context for that sub {},
we might be able to restore that behavior somehow.  that would fix
both issues...  I don't have any bright ideas at the moment)

Ill also point out Tim has more or less pointed out all these
solutions up-thread as well.

Anyone see any other options?  There are hybrid solutions here.  For
instance if we did #1, we could also prepare a patch for 9.1 that will
'opt-in' for the more secure closures and the sort {} fixes.  The
patch would in essence be #3. After that's been field tested for a
while we could see about back patching it.

If wishes were horses we'd all be eating steak.

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2010-02-25 19:20:10
Subject: Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
Previous:From: Bruce MomjianDate: 2010-02-25 18:32:31
Subject: Re: to_timestamp error handling.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group