import.meta.url exposes full file path even when no permissions are given

[josephrocca]

If I create a script:

console.log(import.meta.url);

and run it like this:

deno run script.js

then it logs this:

file:///home/joe/full/path/to/script.js

This is surprising to me, but maybe I'm missing something. I tend to think of Deno like a web browser - and so running some random code that I've downloaded from the internet shouldn't tell someone my name (assuming, for example, that I set --allow-net so they could actually exfiltrate that data).

It seems significant enough that there is probably an existing discussion/resolution on it, but I couldn't find an issue explaining or mentioning this - so apologies if it has already been brought up!

[wperron]

Third-party code can access it, but unless you give Deno access to the filesystem or the network it can't really do anything with it. I'm assuming the concern here is that a third-party library could phone back home and collect information about you without your consent. In that case, I would suggest allowlisting the allowed domain names in the --allow-net parameter

[lucacasonato]

Actually, remote code can not access your local path name without --allow-read. import.meta.url is per module, so only local modules ran from the file system can see a import specifier with your usename in it. If you deno run https://gist.githubusercontent.com/lucacasonato/16f2d638f9a529cd0f21979bf0065d93/raw/8352f1b289973cbc324dbc5244ef256cc3e6c4e9/test.js, the import.meta.url in there will be https://gist.githubusercontent.com/lucacasonato/16f2d638f9a529cd0f21979bf0065d93/raw/8352f1b289973cbc324dbc5244ef256cc3e6c4e9/test.js, not some local path.

[josephrocca]

unless you give Deno access to the filesystem or the network it can't really do anything with it

@wperron Yep, I mentioned that in the issue

Actually, remote code can not access your local path name

@lucacasonato Maybe you were replying to wperron rather than me, but in the issue I said "and so running some random code that I've downloaded from the internet", meaning to imply that I've downloaded the code to my machine, and then ran it. I agree that this is a nice extra layer of protection though (given that most people will be running code via a URL).

And actually, testing this by loading a HTML file with <script type="module">console.log(import.meta.url)</script> via a file:// URL in the browser logs the full file:// URL. I guess that makes sense, since it can of course access window.location.href which contains the same path.

That said, it's quite rare that developers run HTML files on their machine without a local webserver, since a lot of functionality is disabled, so arguably Deno should behave more like the webserver case. I guess that would probably imply that --location would be required to access import.meta.url (from local scripts) in Deno, similar to when accessing window.location.href?

(Off-topic, but that makes me think: Maybe the solution to #2150 is to disallow file:// fetching, but have a special --location TLD - e.g. --location=foo.local which essentially serves the current working directory content with a static file webserver type thing - just like how web developers solve that same file:// fetching problem. I don't use Deno enough or know about the internals enough to know what I'm talking about here though.)

In any case, I'll trust that y'all know what you're doing here - I just thought I'd open this issue in case this was not expected behavior, or in case it could so with some discussion. Please feel free to close if this is considered resolved.

[nayeemrmn]

This is known and intentional. Another case where explicitly downloading modules as opposed running them remotely will grant them an extra privilege is them being immune to #5050. When doing this, users need to take their own measures like putting these modules in an obscured path or using a scoped import map to limit what they can import.

[lucacasonato]

Closing this as working as intended.

[timfish]

It's also worth pointing out that all paths are also accessible in stack traces!

console.log(new Error().stack);