Thread: [PATCH] untrusted plperl
Well, after persuading cvsup and cvs that it _is_ possible to have local
modifiable repositories, I have a clean untrusted plperl patch to offer
you :)
Highlights:
* There's one perl interpreter used for both trusted and untrusted
procedures. I do think its unnecessary to keep two perl
interpreters around. If someone can break out from trusted "Safe" perl
mode, well, they can do what they want already. If someone disagrees, I
can change this.
* Opcode is not statically loaded anymore. Instead, we load Dynaloader,
which then can grab Opcode (and anything else you can 'use') on its own.
* Checked to work on FreeBSD 4.3 + perl 5.5.3 , OpenBSD 2.8 + perl5.6.1,
RedHat 6.2 + perl 5.5.3
* Uses ExtUtils::Embed to find what options are necessary to link with
perl shared libraries
* createlang is also updated, it can create untrusted perl using 'plperlu'
* Example script (assuming you have Mail::Sendmail installed):
create function foo() returns text as ' use Mail::Sendmail;
%mail = ( To => q(you@yourname.com), From => q(me@here.com), Message
=>"This is a very short message" ); sendmail(%mail) or die $Mail::Sendmail::error;
return "OK. Log says:\n", $Mail::Sendmail::log;
' language 'plperlu';
(well, change the name in the To: line :)
Hope someone finds that useful and maybe even merged :)
-alex
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 ;)).
But it'd be nice to get a Perl expert to comment on the thing,
particularly on the safe/unsafe-in-one-interpreter business.
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.
regards, tom lane
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
Alex, seems you have done sufficient research to be sure this is OK. Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. > 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 > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Patch applied. Thanks. Waiting for doc updates. > Well, after persuading cvsup and cvs that it _is_ possible to have local > modifiable repositories, I have a clean untrusted plperl patch to offer > you :) > > Highlights: > * There's one perl interpreter used for both trusted and untrusted > procedures. I do think its unnecessary to keep two perl > interpreters around. If someone can break out from trusted "Safe" perl > mode, well, they can do what they want already. If someone disagrees, I > can change this. > > * Opcode is not statically loaded anymore. Instead, we load Dynaloader, > which then can grab Opcode (and anything else you can 'use') on its own. > > * Checked to work on FreeBSD 4.3 + perl 5.5.3 , OpenBSD 2.8 + perl5.6.1, > RedHat 6.2 + perl 5.5.3 > > * Uses ExtUtils::Embed to find what options are necessary to link with > perl shared libraries > > * createlang is also updated, it can create untrusted perl using 'plperlu' > > * Example script (assuming you have Mail::Sendmail installed): > create function foo() returns text as ' > use Mail::Sendmail; > > %mail = ( To => q(you@yourname.com), > From => q(me@here.com), > Message => "This is a very short message" > ); > sendmail(%mail) or die $Mail::Sendmail::error; > return "OK. Log says:\n", $Mail::Sendmail::log; > ' language 'plperlu'; > > > (well, change the name in the To: line :) > > > Hope someone finds that useful and maybe even merged :) > > -alex Content-Description: plperlu.diff [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026