Re: plperl and sqrt.

From: Travis Bauer <trbauer(at)indiana(dot)edu>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: plperl and sqrt.
Date: 2001-01-18 16:17:26
Message-ID: 20010118111726.A6325@ghost.cs.indiana.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:

>
> There's an "operation mask" inside plperl that defines which Perl
> opcodes it thinks are safe to allow the user to execute. I think
> the mask is set pretty conservatively at the moment ... definitely
> too conservatively, if it rejects sqrt :-(. But no one's gotten
> round to looking at the situation more closely to decide what's
> safe and what's not. Feel free to look at the documentation for
> Perl's Opcode module and propose a more reasonable mask.
>
> regards, tom lane

The existing mask seems the most reasonable. The mast is :default,
which is not the most strict, but reasonably so. It allows users to
write scripts that would consume system resources, tying up the
system, but prevents them (probably) from getting too much access to
the host system. sqrt is disables because you can use it to produce
floating point exceptions which would call $SIG{??}. I'm not sure
why this is bad, but it seems that this would violate the comparment
somehow.

Anyway, it would be nice to have a commandline switch for the
Makefile.PL script which would allow people to customize the
operation mask that plperl.so uses. I have to use the :base_math
mask because I need sqrt. When plperl is re-enabled in the
configure script, it should be added there too.

--
----------------------------------------------------------------
Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer
----------------------------------------------------------------

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Lamar Owen 2001-01-18 16:31:29 Re: RE: Why is there so much MySQL bashing???
Previous Message Gordan Bobic 2001-01-18 16:01:05 Tuning queries and distinct behaviour