Re: [PATCH] untrusted plperl - Mailing list pgsql-hackers

From Alex Pilosov
Subject Re: [PATCH] untrusted plperl
Date
Msg-id Pine.BSO.4.10.10106162337160.8898-100000@spider.pilosoft.com
Whole thread Raw
In response to Re: [PATCH] untrusted plperl  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] untrusted plperl  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Sat, 16 Jun 2001, Tom Lane wrote:

> Alex Pilosov <alex@pilosoft.com> writes:
> > Hope someone finds that useful and maybe even merged :)
> 
> It looks great to me (except you forgot the documentation updates ;)).
My bad! I'll find whereever plperl is mentioned and note plperlu
existance.

> But it'd be nice to get a Perl expert to comment on the thing,
> particularly on the safe/unsafe-in-one-interpreter business.
I'm no expert, and biased since I wrote it this way, but here's the
skinny:

1) safe functions has a unique namespace, and may not escape from it.
(or should not, if Safe module works right). 

2) there were attacks on Safe module that resulted in ability to set
variables outside of your namespace. None known now.

3) There's an existing problem with AUTOLOAD and Safe, which doesn't apply
to us, since you can't 'use' a module in a Safe compartment.

To be truly paranoid, one must have separate interpreters, but that kills
the idea of sharing variables. (Actually, when PgSPI is done (see next
email), it would be possible to do so via SPI).

I'm awaiting opinion of a real perl expert, tho ;)

> One thought that comes to mind: seems like it'd be possible to
> communicate via Perl global variables, functions, etc between
> safe and unsafe functions.  This might be good, or it might be
> a vehicle for bypassing the safety restrictions.  We should
> think hard about that.
Yeah. I thought about that. Thing is, you have to predeclare all variables
you want to share with safe functions. I think it would make sense to have
a global hash, named $safe_info (well, $main::safe_info) which would be
shared. Unfortunately, there's no way to have 'readonly' share, so
safe functions should not rely on $safe_info, as it could be corrupted by
unsafe functions...

-alex



pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: The NOTICE messages
Next
From: Alex Pilosov
Date:
Subject: plperl direction