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:

Reply via email to