Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers