Re: [Tigerlead] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4

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.

In response to

Browse pgsql-bugs by date

  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