Allowing relative file imports

[Georg Wrede]

Walter Bright wrote:
> Daniel Keep wrote:
>> It should be noted that this is really no different to executing
>> arbitrary code on a machine.  That said, compiling a program is not
>> typically thought of as "executing" code, so some restrictions in this
>> case would probably be prudent.
> 
> 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.

As almost everybody else here, I've maintained a couple of websites.

Using D to write CGI programs (that are compiled, real binaries) is 
appealing, but I'd never even think about having the web server itself 
use the D compiler!!!

I mean, how often do you see web sites where stuff is fed to a C 
compiler and the resulting programs run????? (Yes it's too slow, but 
that's hardly the point here.) That is simply not done.

Rdmd might get one thinking of such, but then, how many websites use 
dynamically created PHP? Dynamically created pages yes, but with static 
PHP source.

I must be missing something big here...