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
|
Список | 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 по дате отправления: