-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
src: bootstrap Web [Exposed=*] APIs in the shadow realm #46809
Conversation
Review requested:
|
9801507
to
b5bf1ac
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
src/api/environment.cc
Outdated
// TODO(legendecas): Per-realm prepareStackTrace callback. | ||
// If we are in a Realm that is not the principal Realm (e.g. ShadowRealm), | ||
// skip the prepareStackTrace callback as the context's security token is | ||
// likely to be different. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, why do we need different security tokens? Can we just set the non-principal realm's security token to be the same as the one of the principal realm, like what we do for vm contexts? IIUC security tokens in browsers are generally intended for cross-origin global proxies, which isn't really a thing for Node.js. For shadow realms, the cross-realm access is guarded with wrapped functions and callable boundaries. For Node.js realms, do we care about cross-realm object access?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is true that object exchange across the ShadowRealm boundary is limited with wrapped functions. However, it is still possible for host hooks like the prepareStackTrace callback here to leak objects to the principal realm's userland Error.prepareStackTrace
override.
It doesn't hurt to set the security token to be the principal realm's. But I don't see the reason to allow the access either.
I've updated the comment to point out that this branch is intended to avoid calling the principal realm's Error.prepareStackTrace
override instead of the security token mismatches.
b5bf1ac
to
dee17ae
Compare
CI is has a relevant test failure:
|
dee17ae
to
b204e2f
Compare
Landed in d0153ae...e6b4d30 |
PR-URL: #46809 Refs: #42528 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
This is the initial work to bootstrap Web interfaces that are defined with extended attributes `[Exposed=*]`. The ShadowRealm instances are garbage-collected once it is unreachable. However, V8 can not infer the reference cycles between the per-realm strong persistent function handles and the realm's context handle. To allow the context to be gc-ed once it is not reachable, the per-realm persistent handles are attached to the context's global object and the persistent handles are set as weak. PR-URL: #46809 Refs: #42528 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
PR-URL: #46809 Refs: #42528 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
This is the initial work to bootstrap Web interfaces that are defined with extended attributes `[Exposed=*]`. The ShadowRealm instances are garbage-collected once it is unreachable. However, V8 can not infer the reference cycles between the per-realm strong persistent function handles and the realm's context handle. To allow the context to be gc-ed once it is not reachable, the per-realm persistent handles are attached to the context's global object and the persistent handles are set as weak. PR-URL: #46809 Refs: #42528 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
This is breaking v19.x-staging. Could you please create a manual backport? See: #47441 (comment) |
PR-URL: nodejs#46809 Refs: nodejs#42528 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
This is the initial work to bootstrap Web interfaces that are defined with extended attributes `[Exposed=*]`. The ShadowRealm instances are garbage-collected once it is unreachable. However, V8 can not infer the reference cycles between the per-realm strong persistent function handles and the realm's context handle. To allow the context to be gc-ed once it is not reachable, the per-realm persistent handles are attached to the context's global object and the persistent handles are set as weak. PR-URL: nodejs#46809 Refs: nodejs#42528 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
This is the initial work to bootstrap Web interfaces that are defined
with extended attributes
[Exposed=*]
.The ShadowRealm instances are garbage-collected once it is
unreachable. However, V8 can not infer the reference cycles between
the per-realm strong persistent function handles and the realm's
context handle. To allow the context to be gc-ed once it is not
reachable, the per-realm persistent handles are attached to the
context's global object and the persistent handles are set as weak.
Refs: #42528