Allowing relative file imports

[Georg Wrede]

Andrei Alexandrescu wrote:
> Georg Wrede wrote:
>> 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.
> 
> Of course it is, probably just not in C. Last time I looked, there are 
> two concepts around, one of "statically-generated dynamic pages" and one 
> of "entirely dynamic pages". I know because I installed an Apache server 
> and at that time support for statically-generated dynamic pages was new.
> 
> What that means is this:
> 
> a) statically-generated dynamic = you generate the page once, it's good 
> until the source of the page changes;
> 
> b) "really" dynamic page = you generate the page at each request.
> 
>> 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...
> 
> I think D with rdmd would be great for (a).

I'm still not sure what you mean. I see it as static (as in plain html) 
vs dynamic (as, FaceBook, Wikipedia, etc.). Now these dynamic pages can 
be php pages, that get their data from a database (I guess wikimedia 
would be a good example), but neither case involves creating the server 
side programs (as in *.php, *.cgi) dynamically.

Or sort-of. Many PHP web applications contain pages that dynamically 
choose which sub-elements (say a news ticker) to "show", but that's 
still just combinations of prewritten "mini-pages", if you will. (Some 
even have them in a RDBMS.)

But a use case where one would need to create CGI-BIN stuff that is so 
variable as to warrant recompiling, I don't see. One would rather have a 
set of small D programs (binaries) that do small things, like one for 
latest news, one for informing about others online, etc.

--------

Of course there are sites where I can type D source code in a box, and 
have it compiled and run. But I'm sure neither of us are talking about 
such sites? I mean, to do that, the administrator usually knows what 
he's doing! And can take care of himself, which means we don't have to 
accommodate his needs.