"Try it now"

Daniel Gibson metalcaedes at gmail.com
Thu Apr 14 08:32:44 PDT 2011


Am 14.04.2011 16:56, schrieb spir:
> On 04/14/2011 03:50 PM, David Nadlinger wrote:
>> On 4/14/11 3:44 PM, spir wrote:
>>> On 04/14/2011 02:40 PM, David Nadlinger wrote:
>>>> On 4/14/11 2:26 PM, spir wrote:
>>>>>> Not having any imports makes for a faster compile, too.
>>>>>
>>>>> ... and helps in having safe sandboxes.
>>>>
>>>> In which way exactly do I need an import to write »extern(C) int
>>>> system(in char
>>>> *); system(…);«?
>>>
>>> Did I write "it provides safe sandboxes"?
>>>
>>> Denis
>>
>> No, but you wrote that it »helps in having safe sandboxes«, and I'm
>> curious how
>> you think it would.
> 
> I mean imports usually bring in many more tools for naughty code. And I
> guess in some languages, naughty actions can only be performed via such
> imported modules (system control, direct memory access,...), thus
> forbidding import is an easy way of creating a sandbox. At the very
> minimum, forbidding import or limiting it to a predefined set of modules
> is a necessary first step, I guess.
> 
> Denis

As long as any C function can be called just by defining it, this is
just snake oil. For other languages this may work, but it'd make more
sense to just use a modified standard-lib that asserts when forbidden
functions are used.

For D (and probably any other system programming language) it makes more
sense to restrict on OS level, for example with SELinux, and assume that
the user code is pure evil.

Cheers,
- Daniel


More information about the Digitalmars-d mailing list