Thread: Trusted plperl
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). Regards, -- Mark Steele Vice president research and development Inet Technologies Inc. msteele@inet-interactif.com 010110010110111101110101001000000110000101110010011001010010000001100100011101010110110101100010
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: > > 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). > > Regards, > > -- > Mark Steele > Vice president research and development > Inet Technologies Inc. > msteele@inet-interactif.com > > 010110010110111101110101001000000110000101110010011001010010000001100100011101010110110101100010 > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
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/