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

Restrict access to specific libraries when running code in an isolate #16373

Open
DartBot opened this issue Jan 28, 2014 · 3 comments
Open

Restrict access to specific libraries when running code in an isolate #16373

DartBot opened this issue Jan 28, 2014 · 3 comments
Labels

Comments

@DartBot
Copy link

DartBot commented Jan 28, 2014

This issue was originally filed by george.moscho...@gmail.com


The option to run Dart code in an isolate (e.g. using Isolate.spawnUri) without access to specific libraries is desirable.

Use case: implementation of a simple sandbox for 'safe' code by restricting access to dart:io.

@sgjesse
Copy link
Contributor

sgjesse commented Jan 29, 2014

One option here is to have the ability to install a library resolver when spawning an isolate. Such a resolver will be able to supply the source code for any given library overriding the default.

Related to sandboxing then controlling whether native extensions are supported or not is also relevant.


Removed Type-Defect label.
Added Type-Enhancement, Library-Isolate, Triaged labels.

@lrhn
Copy link
Member

lrhn commented Jan 29, 2014

This request keeps popping up, so we will probably need it eventually.

I'm not sure that intercepting core libraries is a good idea, but running isolates in certain configurations/profiles (e.g., no dart:io, no dart:HTML) should probably be supported.

That would also give a coherent story about why the standalone VM has dart:io and the browser (VM or dart2js) has dart:html - they are running in different, but known, profiles, and it generalizes to other profiles that we might need in the future, or that users might need isolates to run in.
(I.e., a "profile" is a set of allowed platform libraries, and you can spawnUri isolates in a subset of your own profile only).

In the browser, spawnUri isolates do not have access to the HTML DOM. If they run in a profile with no access to dart:HTML, that would be very, very obvious.

We should never allow preventing or modifying dart:core, probably not dart:collection or dart:math either. I can definitely imagine a profile without dart:async.

We might allow querying the current isolate about which profile it is in, but it's probably not relevant - imports happen, and would fail, long before you get to that point.
I don't know how dart2js will handle it, but as with any isolate configuration, they might need to compile the isolate up-front with special flags telling the configuration it will eventually run in, and then test that it's correct when the isolate starts.


cc @floitschG.
cc @a-siva.
cc @iposva-google.

@lrhn
Copy link
Member

lrhn commented Jan 29, 2014

Added Area-Library label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants