Trusted plperl

On Fri, 20 Apr 2001 msteele@inet-interactif.com wrote:

Hey folks, I sent out this question a while back without
ever getting an answer, so here I go again :)

Has anyone managed to compile a trusted plperl interpreter
into postgres? The Opcode stuff which blocks the use of
external modules, and 99% of perl's built-in operators
really bugs me :(

Since my postgres installations will never be accesible by
end-users, there are no risks for me to set up a fully trusted
interpreter. I think that if I could use perl's full power
from inside postgres I could make it do some very impressive
things and might simplify some application development.

I would be more than glad to hack the code myself, but I very
little C. It would be amazing to be able to import abitrary perl
modules straight into a stored functions for those of us
who don't need the extra security that using Opcode provides.

As a side note, the Opcode doesn't really provide that
much security to the imbedded interpreter. Some of the functions
which are allowed by the current setup can be easily used
to crash a system (for example, a badly built regular expression
with backreferences can eat up all available memory in seconds).

(re: the securyti point... there's still a big difference IMHO between
letting people construct memory-murdering regexes and letting them execute
*any arbitrary perl code*, though)

Sorry, no clue how to do this w/plperl.

Without starting a perl/python war (yawn!), if you're python-saavy,
there's a beta-quality release of plpython out there, and this
(a) includes query/trigger/etc support, and (b) is easily modifying so
that additional modules can be loaded above and beyond those included with
the standard distrib.

So, who's going to write pl/visualbasic and pl/logo? ;-)

--
Joel Burton <jburton@scw.org>
Director of Information Systems, Support Center of Washington

I worked on this a bit to get the sqrt function working in the
plperl as distributed. I can't remember offhand the exact change
to the source code. It's one of the plperl c files. You'd only
have to change one or two lines of code (literally) to add in any
additional opcodes.

Even if the opcodes do not provide total security against
crashing the system, they do prevent access to the underlying
filesystem. Using the backquote operators, it would be easy
to write a plperl function that would email a copy of the underlying
database files, for example (if no opcodes prevented
access).

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

msteele@inet-interactif.com (msteele@inet-interactif.com) wrote:

On Fri, Apr 20, 2001 at 03:42:24PM -0400, msteele@inet-interactif.com wrote:

Hey folks, I sent out this question a while back without
ever getting an answer, so here I go again :)

Has anyone managed to compile a trusted plperl interpreter
into postgres? The Opcode stuff which blocks the use of
external modules, and 99% of perl's built-in operators
really bugs me :(

Mark really has a point there.

Why not simply allow access to full perl functionality to postgres
superusers (as with C functions)?

A recent example on pgsql-general has shown that a 15-line pl/pgsql
script can be replaced by a one-line perl expression.

If perl could reach the same level of integration with Pg that mod_perl
has with Apache: full access to the SPI, no restrictions on what can be
done, it would really help us make a quantum leap in productivity.

Programming in pl/pgsql is nice and all, maybe mostly for oracle
refugees, but for most uses it's ridiculously limited and its syntax
reminds of BASIC. It's as far as a modern programming (or scripting)
language as can be. Again creating pl/pgsql was wonderful and
indispensable for oracle migration, but maybe it's the time to give Pg
its swiss-army chainsaw with PERL!

When one considers the power of mod_perl programming, the prospect of
that functionality inside Pg is awe-inspiring.

As a first, immediate step, please free pgperl from its sanbox.

--
ARICIE: Ph�dre en vain s'honorait des soupirs de Th�s�e :
Pour moi, je suis plus fi�re, et fuis la gloire; ais�e
D'arracher un hommage � mille autres offert,
Et d'entrer dans un coeur de toutes parts ouvert.
(Ph�dre, J-B Racine, acte 2, sc�ne 1)

Louis-David Mitterrand <vindex@apartia.ch> writes:

Why not simply allow access to full perl functionality to postgres
superusers (as with C functions)?

The correct way to do this would be to offer an alternative "untrusted
plperl" language, same as we now do for pltcl --- then the dbadmin has
a choice whether to take the risk of installing plperlu or not.

If perl could reach the same level of integration with Pg that mod_perl
has with Apache: full access to the SPI, no restrictions on what can be
done, it would really help us make a quantum leap in productivity.

What plperl needs is some partisans who are actually willing to do some
work. Mark Hollomon did a great job of building a proof-of-concept
implementation (which is all that it really is, at this point), but he
seems to have lost interest since then. It's time for some other Perl
users to step up to the plate.

regards, tom lane

On Fri, Apr 20, 2001 at 03:42:24PM -0400, msteele@inet-interactif.com wrote:

Has anyone managed to compile a trusted plperl interpreter
into postgres? The Opcode stuff which blocks the use of
external modules, and 99% of perl's built-in operators
really bugs me :(

Unfortunately, without support for actually talking to the database
(doing queries, etc.), plperl is not that useful for us. I did once
wish I could have used it for a wrapper around Date::Manip, but then
realized the subset of functionality I actually needed was available
without it.
--
Christopher Masto Senior Network Monkey NetMonger Communications
chris@netmonger.net info@netmonger.net http://www.netmonger.net

Free yourself, free your machine, free the daemon -- http://www.freebsd.org/