Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deno.mainModule should not require permissions #7315

Closed
nayeemrmn opened this issue Sep 1, 2020 · 5 comments · Fixed by #25667
Closed

Deno.mainModule should not require permissions #7315

nayeemrmn opened this issue Sep 1, 2020 · 5 comments · Fixed by #25667
Assignees
Labels
permissions related to --allow-* flags public API related to "Deno" namespace in JS
Milestone

Comments

@nayeemrmn
Copy link
Collaborator

The value of Deno.mainModule is visible in call stacks. In general, we should make it a non-goal to hide information about "calling" code. You can currently hide it from call stacks by moving calls to untrusted code to the top-level of some other insignificant imported module. But the same technique could most likely be used to make sure your Deno.mainModule is insignificant.

This leaves future opportunities to remove import.meta.main in favour of import.meta.url == Deno.mainModule, as was intended by the spec: https://github.com/tc39/proposal-import-meta#am-i-the-main-module. But that means we have to statically substitute Deno.mainModule in bundles, leaving no way to get the "true" main module which some people won't like (#6344 (comment)). Anyway, that discussion can wait.

@kitsonk kitsonk added permissions related to --allow-* flags suggestion suggestions for new features (yet to be agreed) needs discussion this topic needs further discussion to determine what action to take labels Nov 17, 2020
@kitsonk
Copy link
Contributor

kitsonk commented Nov 17, 2020

Hmmm...

The one "problem" with this is that any module could get information about the local system. We have import.meta.main which provides this information, and we have "fixed" what happens with bundles. This means each module can know itself and if it is the main module.

So personally, I think the permissions should stay, taking the conservative viewpoint, until there is a compelling use case we can't work around reasonably.

Actually the point about the stack traces is interesting from a security exploit perspective. I wonder if throwing an error and trapping the trace would expose information about the local file system?

@bartlomieju
Copy link
Member

I hit this problem as well working on Node compatibility - accessing process.argv (which uses Deno.mainModule internally) requires to open full FS read sandbox. I think it's hindering DX in this case, and unless users gave --allow-write there's no harm in allowing to inspect Deno.mainModule without a permission.

@jsejcksn
Copy link
Contributor

jsejcksn commented Dec 1, 2021

and unless users gave --allow-write there's no harm in allowing to inspect Deno.mainModule without a permission

Network access would allow for exfiltrating this information.

@bartlomieju
Copy link
Member

Discussed with other team members, we are going to remove requirement for allow read permission on Deno.mainModule.

@bartlomieju bartlomieju added public API related to "Deno" namespace in JS and removed suggestion suggestions for new features (yet to be agreed) needs discussion this topic needs further discussion to determine what action to take labels Jan 20, 2023
@bartlomieju bartlomieju self-assigned this Jan 20, 2023
@alexandrubau
Copy link

Any updates regarding this topic? Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
permissions related to --allow-* flags public API related to "Deno" namespace in JS
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants