Re: [HACKERS] plperl intial pass

Jan Wieck wrote:
> 
> 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                          ^^^^^^^^^^^^^^^^^

And here-in lies the problem. Tcl_CreateCommand is sitting, not
in the executable, but in the shared-lib with the function call
handler. dlopen(), by default will not link across shared-libs.
         postgres    /-----/  \-----\    |              | plperl.so ---> Opcode.so            ^^
This link doesn't happen.

Passing RTLD_GLOBAL (I think) as a flag to dlopen makes the symbols
in a shared-lib available for linking into the next shared-lib.

But postgresql doesn't use the RTLD_GLOBAL flag and patching the
backend to load _everything_ with RTLD_GLOBAL seemed like it could
have less than desirable behavior.

a.out systems are easier since perl's dynamic loading subsystem
would take care of problem for me.

>     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).

That is exactly how it works. But see above.

And on top of the above problem, postgres assumes all linuxen
use a.out type loading. Where as perl uses dlopen where it can.

Getting those two to play together is more than I care to attempt.
I am researching a fix now to let linux installations use dlopen
if it is available.

I would not be unhappy if somebody beats me to it.

>     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.
> 

Yes, I've been thinking about that as well. It would be nice to have
permissions based on userid. Maybe the 'suid' stuff that is being
discussed in another thread will gives us a mechanism.

-- 

Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008