DMD 1.005 release [security concerns about ImportExpressions]

[Henning Hasemann]

On Wed, 07 Feb 2007 08:30:31 +0200
"Vladimir Panteleev" <thecybershadow at gmail.com> wrote:

> Hmm. What would prevent someone from writing programs like:
>    writef(import("/etc/passwd"));
> and trick someone to compile this program for them (under the pretext that they don't have a D compiler, for example) to steal the user list (or the contents of any other file with a known absolute or relative path on the victim's system)?
> 
> IMO, the compiler should at least issue a warning when importing a file not located in/under the source file's directory. Although, if the source emits a lot of pragma(msg) messages, the warning might get cluttered by those - or this might be concealed in a large program with a lot of files. A better security-wise solution is to disallow importing files outside the source file's directory, unless specified by the user on the command-line.

I whould even go one step further and limit import() to just import files in the -I path.
That whould have a few implications:

- Except you have weird import paths, import() can not lead to include any
  given "evil" file, it should then be as secure or insecure as C's #include
- One whould not be able to include any given file on the fs, but I think
  that shouldnt be a problem, since most of the time the dsl files should lie
  somewhere around in the source-tree.
- You whould use import() much like import, which at least sounds more consistent.
  For example:
  import("foo.d"); whould include the same file as
  import foo; whould import.
  Note that the semantic is still different and that import needs the file extension (as
  it might often be used to include non-d files) where import does not.
  Alternative: Allow import() just to include files with a predifined extension, then
  one could use the package.subpackage.module syntax as well.

Questions that arise to me while writing this:
* since import() does not the same thing as import ...; shouldnt it be renamed to something else?
  (say include)

* if one whould restrict import() to import-paths whould it be senseful to allow subdirectories
  to be specified?
  (say import("files_written_in_my_dsl/foo.dsl"))
  Note here that this whould still not allow directories "above" the import paths.

Henning