vetoの場合

unsafeWindow.consoleにGMからアクセスすると出るのは

#0	0x0f2f67cb in nsScriptSecurityManager::CheckSameOriginPrincipalInternal at nsScriptSecurityManager.cpp:943
#1	0x0f2f6d55 in nsScriptSecurityManager::CheckSameOriginPrincipal at nsScriptSecurityManager.cpp:699
#2	0x0f2eb8d3 in nsPrincipal::Equals at nsPrincipal.cpp:294
#3	0x0f2e9bfe in nsPrincipal::Subsumes at nsPrincipal.cpp:306
#4	0x0aa57893 in CanCallerAccess at XPCSafeJSObjectWrapper.cpp:145
#5	0x0aa57d51 in XPC_SJOW_Construct at XPCSafeJSObjectWrapper.cpp:883
#6	0x01063f8a in js_Invoke at jsinterp.c:1356
#7	0x010642d8 in js_InternalInvoke at jsinterp.c:1432
#8	0x01091ed4 in js_ConstructObject at jsobj.c:2849
#9	0x0101ac8a in JS_ConstructObjectWithArguments at jsapi.c:2981
#10	0x0aa58190 in WrapJSValue at XPCSafeJSObjectWrapper.cpp:252
#11	0x0aa58a23 in XPC_SJOW_GetOrSetProperty at XPCSafeJSObjectWrapper.cpp:577
#12	0x0aa58a94 in XPC_SJOW_GetProperty at XPCSafeJSObjectWrapper.cpp:583
#13	0x01093ca6 in js_NativeGet at jsobj.c:3528
#14	0x010946c2 in js_GetProperty at jsobj.c:3671
#15	0x01073d7e in js_Interpret at jsinterp.c:3817
#16	0x01064911 in js_Execute at jsinterp.c:1601
#17	0x01020dbf in JS_EvaluateUCScriptForPrincipals at jsapi.c:4858
#18	0x0aa1aaf1 in xpc_EvalInSandbox at xpccomponents.cpp:3531

こうなって出てる。
callerのprincipalはcodebaseがsystemになってた。evalInSandboxでもprincipalはsystemになることがわかった。
unsafeWindowのprincipalはcodebaseが開いているページのuriだった。結果としてvetoされるのはわかった。

問題はほかの場合をどう考えたらいいのかだ。
考えるべきなのはみっつで二種類。

GMのsandboxに設定したプロパティの__parent__が取れない理由

これは脆弱性、全てのサイトでGM_xmlhttpRequestを使う、解説と回避 - 実用のbugzillaのコメントからすると使用上安全っていう話に思えるけど仕様がわかってないのでわからない。

コンテキストをまたいでevalの第二引数からたどれない理由

sandboxでComponents.classesとかにアクセスできない理由

sandboxからはアクセスできないので、principalとComponentsにアクセスできるかどうかは別のことだっていうのがわかっている。Components.*へのアクセスは何で管理されているか。

permission deniedじゃなくてvetoって出るほうはsecman管理で Security check basics - MDC 読んだらわかる。evalInSandboxとかどーなってんだと思って調べた。sandboxはsystemになってる。
なってない。Firebug Consoleからの場合、できたsandboxのprincipalはページのcodebaseになってた。

__parent__がなんなのかもいまだにわかってない... ecmaの仕様書読んだらわかるというのはわかった。