Re: Can we still trust plperl?

On Thu, Mar 11, 2010 at 09:31:46AM -0500, Andrew Dunstan wrote:
>
> Last night my attention was drawn to this:
>
> <http://search.cpan.org/~timb/PostgreSQL-PLPerl-Injector-1.002/lib/PostgreSQL/PLPerl/Injector.pm>
>
> I'm wondering if we can reasonably continue to support plperl as a trusted 
> language, or at least redefine what "trusted" actually means. Does it mean 
> "can't do untrusted operations" or does it mean "can't do untrusted 
> operations unless the DBA and/or possibly the user decide to subvert the 
> mechanism"? To me, the latter doesn't sound much like it's worth having. Is 
> it?
>
> There are a few places where plperl has an advantage over plpgsql, e.g. 
> code that uses lots of regexes and use of variable to access records 
> dynamically, so losing it might be a bit of a pain. Of course, there would 
> still be plperlu, with the downside that the functions have to be installed 
> by a superuser. One of my PGExperts colleagues told me his reaction was 
> "Well, I might just as well use plperlu", and that pretty well sums up my 
> reaction.
>
> Of course, another thing is that it might spur either building of some of 
> the missing stuff into plpgsql, or addition of another language that is 
> both safe and which supports them, like say PL/JavaScript.
>
> Thoughts?
>
> cheers
>
> andrew
>
The DBA can do what ever he wants to do to subvert the system up to
installing hacked versions of any other "trusted" language so I do
not see much of a distinction. We already provide many other foot-guns
that may be used by the DBA. pl/perl is very useful as a trusted
language but I am certainly for fleshing out the features in other
pl-s.

Regards,
Ken