On Fri, May 21, 2010 at 7:25 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Fri, May 21, 2010 at 12:22 PM, David Fetter <david@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 <josh@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
