Graaljs: Ability to have a clean EcmaScript Context

Created on 4 Jan 2019  路  9Comments  路  Source: oracle/graaljs

I'm trying to get a Context that only contains plain EcmaScript API, so not stuff like print, Polyglot or Java, as I want to sandbox the (3rd-party) scripts I'll be running in the Context.

I've called .allowAllAccess(false) on my Context builder, but it seems that the aforementioned print/Polyglot/Java objects/functions are still available (albeit maybe non-functioning, didn't test that).

I saw in the Release Notes that over the last couple of RC's a lot of extensions are already moved to the Nashorn compatibility layer and/or disabled by default, but it seems it's not yet possible to get a real clean, EcmaScript-only Context.

On Gitter it was suggested to remove the unwanted stuff after context creation by evaling something like delete this.xxxxx but that feels a bit like a hack

enhancement

Most helpful comment

When creating a Polyglot Context, you can use the out and err methods of Context.Builder to redirect stdout and stderr for that particular context. As in node.js, the log, info and debug methods of console will then print to stdout, whereas the warn and error methods will print to stderr.

If not desired, the console object can be disabled by setting the console option to false.

All 9 comments

Hi Paul,

thanks for your question. I take from you question you are using Polyglot Context to create the engine (the answer (the defaults) might be different if you used the js command of GraalVM [1], or a ScriptEngine).

You are right on Java and Polyglot. Those builtins should not be available if you turn off access to those features. Right now they are still available, but not useful, (Exception in thread "main" TypeError: Java Interop is not available). We will fix that.

As for the other methods available (I see only 4, but will double-check: print, printErr, load, loadWithNewGlobals): I think users want to have access to them, so I don't think we will change the defaults here. We could think about having a flag to not provide them.

Best,
Christian

[1] e.g., in the GraalVM js binary (i.e. in a "shell" mode) we also provide quit, readline, read and readbuffer.

I'm indeed using the Polyglot Context API from Java to create my Contexts.

Tnx for removing Java/Polyglot if their use is disabled.

As for the other methods availble: based on https://github.com/graalvm/graaljs/blob/master/docs/user/JavaScriptCompatibility.md I found those 4 as well (most other additions seem to be behind flags already (assuming that if disabled by flags, they aren't added as Java and Polyglot are right now)). Whether or not users want those available really depends on the use-case. In my case I obviously don't want them :-)

The only that, based on the documentation, you might have missed is console: although available in many JS runtimes, it's not part of the EcmaScript standard. I'm not sure what the backend logging mechanism is for the console implementation, but in my use-case, I would want a console implementation to be available, but being able to handle/redirect the actual logging on a context-by-context basis. Not sure if the current console implementation is capable of that or if that would be a reasonable request to ask. So this one should also be possible to disable/exclude imho, so if you have specific needs as an embedder, you could choose to roll your own

When creating a Polyglot Context, you can use the out and err methods of Context.Builder to redirect stdout and stderr for that particular context. As in node.js, the log, info and debug methods of console will then print to stdout, whereas the warn and error methods will print to stderr.

If not desired, the console object can be disabled by setting the console option to false.

@jirkamarsik tnx for the info.

That console option: it that one for a plain JavaScript Polyglot Context right? I don't see that option mentioned on https://github.com/graalvm/graaljs/blob/master/docs/user/JavaScriptCompatibility.md

And I guess it's js.console?

Yes, it is js.console. The best way to print the available options currently is from a GraalVM instance, using js --help:languages.

We'll add better documentation to https://github.com/graalvm/graaljs/blob/master/docs/user/JavaScriptCompatibility.md to make options like this one more visible.

We've just merged a PR that brings several new options:

  • js.print (set to false to disable print, printErr)
  • js.load (set to false to disable load, loadWithNewGlobal)
  • js.polyglot-builtin (set to false to disable the Polyglot builtin)

and with "disable", I mean "make it not available in the (global) context".

Java is only visible if interop to Java is allowed.

Together with the js.console, and js.graal-builtin both set to false, that should give you the clean ECMAScript compliant context. We thought about having one option to combine all that; we might add that in the future but did not want to rush that now.

Excellent! Any idea when to expect RC11?

RC11 should be available early next week.

I am closing this. If you have any more issue, please reopen or create a new ticket, thanks!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pmlopes picture pmlopes  路  3Comments

stevenschlansker picture stevenschlansker  路  3Comments

lucifer1004 picture lucifer1004  路  3Comments

fniephaus picture fniephaus  路  7Comments

sagenschneider picture sagenschneider  路  4Comments