On Fri, May 21, 2010 at 7:25 PM, Magnus Hagander <mag...@hagander.net> wrote: > On Fri, May 21, 2010 at 12:22 PM, David Fetter <da...@fetter.org> wrote: >> On Fri, May 21, 2010 at 11:57:33AM -0400, Magnus Hagander wrote: >>> On Fri, May 21, 2010 at 11:55 AM, Josh Berkus <j...@agliodbs.com> wrote: >>> > So, here's a working definition: >>> > >>> > 1) cannot directly read or write files on the server. >>> > 2) cannot bind network ports >>> >>> To make that more covering, don't yu really need something like >>> "cannot communicate with outside processes"? >> >> These need to be testable conditions, and new tests need to get added >> any time we find that we've missed something. Making this concept >> fuzzier is exactly the wrong direction to go. > > Well, the best way to define what a trusted language can do is to > define a *whitelist* of what it can do, not a blacklist of what it > can't do. That's the only way to get a complete definition. It's then > up to the implementation step to figure out how to represent that in > the form of tests.
Yes, PL/Perl is following this approach. For a whitelist see plperl_opmask.h (generated by plperl_opmask.pl at build phase). -- Alexey Klyukin www.CommandPrompt.com The PostgreSQL Company - Command Prompt, Inc -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
