Andrew Dunstan <andrew@dunslane.net> writes:
> 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?
AFAICS the DBA has to participate in setting up that module, so it's
no different from any other PL language. You can insert stuff into the
trusted interpreter in pltcl too. It's on the DBA's head to not insert
stuff that's insecure --- so what? To my mind it's a feature not a
bug that this is possible. It's just like the on_init work that you've
been doing; it's about letting the DBA have control over what users of
the trusted language can get at.
What bothers me more is the fact that genuine holes are beginning to
show up in Safe. I wonder if we aren't seeing the first stages of what
happened to trusted plpython. Building a secure sandbox feature into
a language that wasn't designed for it is hard. However, I'm not going
to panic until there's reason for panic, and this doesn't look like a
reason.
regards, tom lane