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@debis.com (Jan Wieck) #