From: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> |
---|---|
To: | "David E(dot) Wheeler" <david(dot)wheeler(at)pgexperts(dot)com> |
Cc: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: [Tigerlead] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4 |
Date: | 2010-02-19 20:56:32 |
Message-ID: | 20100219205632.GJ373@timac.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Feb 19, 2010 at 09:00:59AM -0800, David E. Wheeler wrote:
> On Feb 19, 2010, at 1:13 AM, Tim Bunce wrote:
>
> >> Hrm. I don't have this bug with Safe 3.19, FWIW.
> >
> > That's because Safe 1.19 (which I presume you meant) doesn't execute
> > closures 'inside' the Safe compartment. So when the regex executes at
> > runtime the C code looks up the utf8::SWASHNEW method without a problem.
>
> Oh, so 2.19 is less secure in that regard, yes?
Yes.
When code that was compiled outside the compartment is executed by a
plperl function, including internal regex implementation code, that
code could call eval/require/do etc. and the newly compiled code
wouldn't have any restrictions. With Safe 2.20+ the newly compiled code
is subject to the same restrictions as plperl.
So what we're seeing is the knock-on effects of that tighting of security.
That's why I'd rather move forward rather than back (though there have
been times over the last 48 hours where moving back to Safe 1.19 looked
very appealing :)
Tim.
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Bunce | 2010-02-19 21:00:34 | Re: BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4 |
Previous Message | Heikki Linnakangas | 2010-02-19 20:07:31 | Re: Fw: Postgress-Crashing |