Re: Trusted plperl

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)