Re: [PATCH] untrusted plperl

Поиск
Список
Период
Сортировка
От Alex Pilosov
Тема Re: [PATCH] untrusted plperl
Дата
Msg-id Pine.BSO.4.10.10106162337160.8898-100000@spider.pilosoft.com
обсуждение исходный текст
Ответ на Re: [PATCH] untrusted plperl  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] untrusted plperl  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Michael Meskes
Дата:
Сообщение: The NOTICE messages
Следующее
От: Alex Pilosov
Дата:
Сообщение: plperl direction