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

Do not copy value onto vm sandbox in strict mode #7908

Closed
wants to merge 1 commit into from

Conversation

fhinkel
Copy link
Member

@fhinkel fhinkel commented Jul 28, 2016

Checklist
  • make -j4 test (UNIX)
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

src

Description of change

In vm, the setter interceptor should not copy a value onto the sandbox, if setting on
the global object will fail because we are in strict mode and the variable is not declared.

Fixes #5344

/cc @bnoordhuis @hashseed @ofrobots

@nodejs-github-bot nodejs-github-bot added the c++ Issues and PRs that require attention from people who are familiar with C++. label Jul 28, 2016
@addaleax addaleax added the vm Issues and PRs related to the vm subsystem. label Jul 28, 2016
const ctx = vm.createContext();

vm.runInContext('w = 1;', ctx);
assert.equal(1, ctx.w);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: use assert.strictEqual wherever it makes sense

@Fishrock123
Copy link
Contributor

bool is_contextual_store = ctx->global_proxy() != args.This();

bool set_property_will_throw = args.ShouldThrowOnError()
&& !is_declared.FromJust() && is_contextual_store;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nit: the readability of this expression would be better if the FromJust were to be done above as part of the definition of is_declared.

@fhinkel
Copy link
Member Author

fhinkel commented Jul 28, 2016

Failed on Windows:

Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
FATAL: Command "git clean -fdx" returned status code 1:

I guess that's unrelated to the change?

@ofrobots
Copy link
Contributor

Another attempt: https://ci.nodejs.org/job/node-test-pull-request/3448/

@ofrobots
Copy link
Contributor

LGTM, but it would be good to get @hashseed and @bnoordhuis to sign-off as well. The arm64 buildbot seems to have run infrastructure issues (it passed in the earlier build). I would consider the CI to be green.

@hashseed
Copy link
Member

LGTM. As discussed, this hinges on getting the prediction right. However, since that part is specified in ECMA262, I think it won't change anytime soon.

bool is_contextual_store = ctx->global_proxy() != args.This();

bool set_property_will_throw = args.ShouldThrowOnError()
&& !is_declared && is_contextual_store;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Style nit: && should go on previous line. I'd write it as:

bool set_property_will_throw =
    args.ShouldThrowOnError() &&
    !is_declared &&
    is_contextual_store;

@bnoordhuis
Copy link
Member

LGTM with some style nits.

const vm = require('vm');
const ctx = vm.createContext();

vm.runInContext('w = 1;', ctx);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor nit... would you mind adding a short comment here about what precisely this test is verifying? ... just to make it easier for other devs who are looking at this test in the future.

@jasnell
Copy link
Member

jasnell commented Jul 29, 2016

LGTM with a nit.

@fhinkel fhinkel force-pushed the i5344 branch 2 times, most recently from b560a65 to ba84d34 Compare July 30, 2016 06:09
In vm, the setter interceptor should not copy a value onto the
sandbox, if setting it on the global object will fail. It will fail if
we are in strict mode and set a value without declaring it.

Fixes nodejs#5344
@fhinkel
Copy link
Member Author

fhinkel commented Jul 30, 2016

Style nits addressed and added a comment explaining the tests.

@cjihrig
Copy link
Contributor

cjihrig commented Aug 1, 2016

LGTM. Another CI run after changes: https://ci.nodejs.org/job/node-test-pull-request/3481/

@jasnell
Copy link
Member

jasnell commented Aug 1, 2016

LGTM with the changes! Thank you!

@jasnell
Copy link
Member

jasnell commented Aug 1, 2016

Build bot failure on Windows on the last CI run... trying again: https://ci.nodejs.org/job/node-test-pull-request/3486/

@Trott
Copy link
Member

Trott commented Aug 2, 2016

More buildbot failures. Let's try again. CI: https://ci.nodejs.org/job/node-test-pull-request/3495/

@fhinkel
Copy link
Member Author

fhinkel commented Aug 2, 2016

Green. Thanks!

jasnell pushed a commit that referenced this pull request Aug 4, 2016
In vm, the setter interceptor should not copy a value onto the
sandbox, if setting it on the global object will fail. It will fail if
we are in strict mode and set a value without declaring it.

Fixes: #5344
PR-URL: #7908
Reviewed-By: Ali Ijaz Sheikh <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
@jasnell
Copy link
Member

jasnell commented Aug 4, 2016

Landed in 588ee22! Thank you!

@jasnell jasnell closed this Aug 4, 2016
@ofrobots
Copy link
Contributor

ofrobots commented Aug 4, 2016

This might be good a good candidate backport to 6.x and possibly 4.x (if the issue is present there).

@cjihrig cjihrig mentioned this pull request Aug 8, 2016
cjihrig pushed a commit that referenced this pull request Aug 10, 2016
In vm, the setter interceptor should not copy a value onto the
sandbox, if setting it on the global object will fail. It will fail if
we are in strict mode and set a value without declaring it.

Fixes: #5344
PR-URL: #7908
Reviewed-By: Ali Ijaz Sheikh <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
@cjihrig cjihrig mentioned this pull request Aug 11, 2016
@MylesBorins
Copy link
Contributor

@fhinkel it would appear that this problem exists on v4.x but ShouldThrowOnError() does not exist in the version of V8 in v4.x

Would you be able to backport?

@fhinkel
Copy link
Member Author

fhinkel commented Oct 11, 2016

Sounds like the API version is too old, I don't think we can easily backport :(

@MylesBorins
Copy link
Contributor

@fhinkel do you think that this bug is bad enough to come up with another solution, or should we just let it be?

@fhinkel
Copy link
Member Author

fhinkel commented Oct 11, 2016

Let it be. That's fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. vm Issues and PRs related to the vm subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

VM: weird behaviour in runInContext/runInThisContext