Recently while doing a little research on how we could do perl module preloading nicely, I constructed the following:

 create function loadmods() returns void language plperlu as $$
   use LWP::UserAgent;
 select loadmods();
 create function loadurl() returns text language plperl as $$
   my $ua = LWP::UserAgent->new;
   my $response = $ua->get('');
   return $response->as_string;
 select loadurl();

This works because plperl and plperlu share a common interpreter. I have thought some about whether or not it is a security risk, and decided it probably isn't, because only a superuser could construct the plperlu function to load the external module - if an ordinary user tried it in trusted plperl code there would be a perl error generated. It remains true that a plperl function cannot on its own get access to an external module, and to that extent we haven't broken the trust criteria. The only way I know of in which we could actually prevent this effect would be to run separate interpreters for plperl and plperlu. That wouldn't be a great tragedy on its own, as perl interpreters aren't hugely heavy objects, but we would probably break some legacy code, and it would take a not insignificant coding effort. So we'd want to be very sure we wanted to do that - personally I can live with this easily enough - the superuser just has to be careful what they do. In cases of paranoia they could use Symbol::delete_package() when they were done with the module, although constantly loading and unloading a module won't perform very nicely.

Anyway, it is probably not expected by many users that loading a module in plperlu makes it available to plperl - I was slightly surprised myself to see it work and I am probably more aware than most of perl and plperl subtleties. I think therefore that at least this should be documented.




---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to