Re: [HACKERS] plperl intial pass

Mark Hollomon wrote:
>
> Jan Wieck wrote:
> >
>
> Correct. The problem is that the Opcode module, which allows you to
> disable features of the compiler (to close security holes) is an
> XS module. In theory, it is possible to do without Opcode, but
> doing so would create a very heavy perl version dependency in plperl.
>
> So, I have to get XS stuff working in order to disallow XS stuff.
> sigh.
>
> And plperl can never be trusted until I can forbid writing to the
> filesystem.

I see. Maybe it's possible to get the Opcode stuff working
without full XS? Adding full XS support only to disable it -
what an overkill :-)

Correct me if I'm wrong (I'm only guessing). Like for Perl,
the Tcl interpreter itself sits in a library. To create the
standalone tclsh, a small tclAppInit.c file is compiled into
the tclsh executable. The default one only creates one
interpreter and arranges for the execution of the script
given in argv[0] or starts up the interactive shell.

A dynamically loadable Tcl module contains one special
function named <libname>_Init() where first character of
libname is capitalized. On dynamic load, this function is
called with the invoking interpreter as argument. This
function then calls Tcl_CreateCommand() etc. to tell Tcl
what's coming here and does other module specific
initializations.

It is now possible, to add other stuff to tclAppInit.c (like
calls to Mymodule_Init) and link it against some more than
libtcl.so. That was the standard solution before dynamic
loading was that easy as it is today (back in the days of
a.out libs).

Your plperl.c is mostly my pltcl.c - so I assume it does the
same things mainly. Create an interpreter and throw some
strings into it, hoping they are intelligable in some way (at
least produce a helpful error message). Thus, it might be
possible to add calls to the initializations for the Opcode
XS directly into the plperl module after creating the
interpreter and link it against Opcode as well.

This is just the way I would do it for Tcl and I'll surely do
it someday. I would like to have a second, unsafe
interpreter in the module. That could then modify files or
use the frontend library to access a different database on
another server. Needless to say that this then would be an
untrusted language, available only for db superusers.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #