Allowing relative file imports

[Jarrett Billingsley]

On Wed, Mar 25, 2009 at 2:18 PM, Walter Bright
<newshound1 at digitalmars.com> wrote:
>
> Here's the scenario I'm concerned about. Let's say you set up a website that
> instead of supporting javascript, supports D used as a scripting language.
> The site thus must run the D compiler on the source code. When it executes
> the resulting code, that execution presumably will run in a "sandbox" at a
> low privilege level.
>
> But the compiler itself will be part of the server software, and may run at
> a higher privilege. The import feature could possible read any file in the
> system, inserting it into the executable being built. The running executable
> could then supply this information to the attacker, even though it is
> sandboxed.
>
> This is why even using the import file feature must be explicitly enabled by
> a compiler switch, and which directories it can read must also be explicitly
> set with a compiler switch. Presumably, it's a lot easier for the server
> software to control the compiler switches than to parse the D code looking
> for obfuscated file imports.
>

One, you do not use Javascript as a server-side scripting language.
That task is usually relegated to (shiver) PHP, Ruby, Python, Java or
the like.  Javascript, as far as I know, only has a place in web
programming in client-side (browser-side) scripting.  The only thing
you can do from the client is maybe munge some POST data, and then
that's a logic error on the part of your server script, not anything
to do with the language.

Two, if you did replace your server-side scripting language with
something like D, there are no more or fewer security holes than with
any other server-side scripting language.  The entire point of
server-side scripts is that they are invisible to the clients, and the
clients never see, modify, or upload server-side scripts of their own.
 It's not possible to put a malicious file import in the D server page
unless you actually have access to the server, and if an attacker does
have that kind of access, D is no more or less secure than any other
server-side language.  They'd all be vulnerable.  The attacker could
just change the server's compiler flags to change the import directory
anyway.

I understand your desire to restrict the use of import expressions,
but your example just does not add up.