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

API call to re-copy internal built-in references from target object #566

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

svaarala
Copy link
Owner

Ecmascript semantics differentiate between the current value and the initial value of certain built-ins. For example for Array constructor:

The [[Prototype]] internal property of the newly constructed object is set to the original Array prototype object, the one that is the initial value of Array.prototype (15.4.3.1).

Duktape implements this internally by keeping an internal array (thr->builtins[]) of built-in object references needed to implement correct semantics.

This is a current limitation in sandboxing however: there's no way to replace these internal references which means that even if sandboxing code replaces e.g. Array.prototype with a custom value, the original Array prototype may still be referenced when one creates an Array literal.

This pull request is a possible solution: add an API call which copies current values of the important built-in references from a target object into the internal reference array. For example, obj.Duktape would be copied to thr->builtins[DUK_BIDX_DUKTAPE].

Compared to other alternatives this is nice because the internal structure, the array model or its indices, is not exposed. Adding or removing values from the internal array has no API impact, but will still correctly update any new internal references required for new semantics.

Open issues:

  • Target object could be the new global object, so that this call would also deprecate duk_set_global_object() and resolve its limitations.
  • Most internal values can be looked up through the global object, but not all: what about e.g. global environment record? Should user code provide it, or should it be automatically recreated as an internal implementation detail?
  • What to do if copying fails due to an error? (Most likely: leave a partially updated array in place.)

Tasks:

  • Finalize API model
  • Implement new API, copy list can be a sequence of (stridx, bidx) pairs (plus maybe a few exceptions)
  • API testcases
  • API documentation
  • Sandboxing documentation
  • Sandboxing example
  • Figure out what to do about duk_set_global_object(): can it be deprecated (and removed in Duktape 2.x) with this API call in place?
  • Releases

@jberryman
Copy link

Probably silly question: Is the goal here just to be able to minimize the possible attack surface, e.g. potential bugs in one of the Array methods? Or is there a particular reason that accessing .prototype might be dangerous?

I'm really appreciating the sandboxing doc, thank you!

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

Successfully merging this pull request may close these issues.

2 participants