Allowing relative file imports

[Daniel Keep]

There seem to have been a few tickets thus far from people wanting to do
relative file imports using the -J switch.  Walter has stated that this
is explicitly disallowed as a defensive measure, which is fine.

I was going to post the following as an enhancement request, but I
thought it might be better if it was discussed first.

TLDR: relative paths should be safe if we disallow symlinks, disallow -J
to be used except for a small whitelist and require a specially-named
file to be present in any imported directory.

Disclaimer: I'm not a security guru.

  -- Daniel

There have been at least two reports thus far (2103 and 2759) of people
attempting to use relative imports with the -J compile-time file import
feature.

It has been stated that this is explicitly disabled due to security
concerns.

I suggest that adding relative paths (provided paths cannot escape the
base directory) is not less secure; it should already be possible to
read an arbitrary file using the feature.

Let us assume relative paths are allowed, and that the path is
"collapsed" to remove all parent (..) references, and clipped to the
base directory.  The only way to "escape" this directory is for one of
three things to happen:

1. there is a symlink to a parent directory in the import path,
2. there is a device of interest mounted in the import path or
3. the user was tricked into specifying a higher directory in the first
place.

Clearly, #3 is already a problem: one could always specify -J/etc in a
Makefile to read any system configuration file that the user has access
to.  #2 is only a problem if the compiling user is an administrator and
tremendously stupid, which is not so much an issue with DMD but with the
user.  #1 is something which could also be done in a Makefile.

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.

Therefore, I believe the following should be sufficient to ensure
relative paths are safe to include:

1. Ensure that symlinks are NOT followed.  This also applies under
Windows for junctions and symlinks (I believe it should be enough to use
GetFileAttributesEx on each path component and reject it if it has the
FILE_ATTRIBUTE_REPARSE_POINT attribute, although I cannot verify this
with XP; see
http://blogs.msdn.com/oldnewthing/archive/2004/12/27/332704.aspx).

2. Disallow -J to be the root of any drive or filesystem, and only allow
-J to be used from the following roots: %USERPROFILE% for Windows and ~
for *nix.  Possibly, this should be configured or overridable in sc.ini;
an extendible whitelist would be good.

3. Require that any directory you attempt to read from using file
imports MUST have either a "_import" or ".import" file (or whatever name
seems appropriate) present in it.

The first should prevent symlinks from being a potential attack vector,
the second should prevent most casual malicious behaviour, and the third
will ensure that the user not only have read access but WRITE access as
well (or whoever owns the directory explicitly allowed for D file imports.)

This should hopefully be sufficient to allow for relative imports.