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(at)nortelnetworks(dot)com
ESN 451-9008 (302)454-9008