[Webkit-unassigned] [Bug 38705] chromium fails http/tests/sandbox-inherit-to-initial-document-2

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Aug 5 12:58:57 PDT 2010


--- Comment #22 from Rajiv Makhijani <rajivmakhijani at chromium.org>  2010-08-05 12:58:56 PST ---
(In reply to comment #19)
> Maybe I've lost context, but I don't understand why we want to ignore the sandbox bit when deciding whether a frame can execute script.

In the situation which test case addresses, the parent window is trying to get access to one of its sandboxed iframes via window.frames[]. It should only be able to do this if the iframed page is on the same origin and the sandbox attribute has the keyword "allow-same-origin". The sandboxed page should still be prevented from executing scripts, but the parent page should be able to access the sandboxed page's DOM via Javascript executing in the parent:


| The allow-same-origin attribute is intended for two cases.
| First, it can be used to allow content from the same site to be sandboxed to disable scripting, while still | | allowing access to the DOM of the sandboxed content.

In the current situation, the WebCore::ScriptController::canExecuteScripts check in WebCore::V8Proxy::retrieve is preventing WebCore::V8DomWindow::indexedPropertyGetter from giving the parent page access to the sandboxed iframe, unless the sandbox attribute has also allowed scripting in the iframe (via "allow-scripts" in the sandbox attribute).


However, from my understanding, it seems like removing this check didn't work because there are cases where no JS Context/Proxy to allow access to the DOM is even created for the iframe (such as in about:blank). This does not appear to be the case when the sandbox prevents execution of scripts in the iframe though.

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list