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('http://search.cpan.org/');
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.
thoughts?
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
