XPConnect:Security:XPCNativeWrapper Automation: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
(9 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
Notes on the new XPConnect security model [https://bugzilla.mozilla.org/show_bug.cgi?id=281988 bug 281988]. | == Notes on the new XPConnect security model == | ||
See [https://bugzilla.mozilla.org/show_bug.cgi?id=281988 bug 281988]. | |||
* Reimplement XPCNativeWrapper in C++ as part of XPConnect, in order to | |||
** wrap deeply, yet lazily | |||
*** so that chrome authors don't have to (remember to) wrap parents, children, grand-children, etc. | |||
** automatically wrap content natives accessed from chrome | |||
*** even less for chrome authors to (have to, therefore fail to ;-) remember | |||
** automatically unwrap when appropriate | |||
** preserve object equality in JS (== and != but not === and !==) | |||
** improve performance over the scripted implementation | |||
* Optimize the chrome-accesses-content test using JS engine changes | |||
** a new GCF_SYSTEM flag for objects | |||
*** to distinguish chrome from content objects | |||
*** using the one spare bit above the lock bit for objects | |||
** new JS_IsSystemObject and JS_GetTopScriptFilenameFlags APIs | |||
** new JS_FlagSystemObject and JS_FlagScriptFilenamePrefix APIs | |||
*** JS_FlagScriptFilenamePrefix allows the embedding to preconfigure script filenames as "system" by setting filename prefixes | |||
*** these filename prefixes are pinned for the life of the JSRuntime | |||
* Extend our extension model compatibly | |||
** support extensions sharing content wrappers | |||
*** do not risk breaking extensions by imposing automated XPCNativeWrapper | |||
*** evangelize extension authors, convert them one by one | |||
*** when enough have converted, we can flip the default wrapper sharing policy | |||
** allow app and extension files to opt into XPCNativeWrapper automation | |||
** this means a wrapper-sharing policy declaration in the chrome manifest | |||
* Resolved issues | |||
** should "system" applied to a script mean has system principals, or wants system XPCNativeWrapper? | |||
** if so, we have enough bits, and HasSystemPrincipal checks can be optimized | |||
** if not, we need another bit, for wrapper sharing policy, per script filename (but not object) as opposed to a fast has-system-principals test | |||
*** JS_FlagScriptFilenamePrefix can take a flags argument | |||
*** do we want JS_UnflagScriptFilenamePrefix? do we ever unload chrome? | |||
** the resolution: | |||
*** bsmedberg will support an xpcnativewrappers=yes option in the chrome manifest | |||
*** this will cause chrome to get the XPConnect service and call its new wantXPCNativeWrappers(filenamePrefix) method | |||
*** which will call JS_FlagScriptFilenamePrefix | |||
* Open Issues | |||
** bz may have --enable-extensions=all, is seeing double-auto-reg on every start (I am seeing single, separate bug) | |||
** this leads to a restart with zero live contexts, apparently, and some prefixes are lost | |||
** never to be re-added (although all are added at least twice) |
Latest revision as of 03:51, 19 May 2005
Notes on the new XPConnect security model
See bug 281988.
- Reimplement XPCNativeWrapper in C++ as part of XPConnect, in order to
- wrap deeply, yet lazily
- so that chrome authors don't have to (remember to) wrap parents, children, grand-children, etc.
- automatically wrap content natives accessed from chrome
- even less for chrome authors to (have to, therefore fail to ;-) remember
- automatically unwrap when appropriate
- preserve object equality in JS (== and != but not === and !==)
- improve performance over the scripted implementation
- wrap deeply, yet lazily
- Optimize the chrome-accesses-content test using JS engine changes
- a new GCF_SYSTEM flag for objects
- to distinguish chrome from content objects
- using the one spare bit above the lock bit for objects
- new JS_IsSystemObject and JS_GetTopScriptFilenameFlags APIs
- new JS_FlagSystemObject and JS_FlagScriptFilenamePrefix APIs
- JS_FlagScriptFilenamePrefix allows the embedding to preconfigure script filenames as "system" by setting filename prefixes
- these filename prefixes are pinned for the life of the JSRuntime
- a new GCF_SYSTEM flag for objects
- Extend our extension model compatibly
- support extensions sharing content wrappers
- do not risk breaking extensions by imposing automated XPCNativeWrapper
- evangelize extension authors, convert them one by one
- when enough have converted, we can flip the default wrapper sharing policy
- allow app and extension files to opt into XPCNativeWrapper automation
- this means a wrapper-sharing policy declaration in the chrome manifest
- support extensions sharing content wrappers
- Resolved issues
- should "system" applied to a script mean has system principals, or wants system XPCNativeWrapper?
- if so, we have enough bits, and HasSystemPrincipal checks can be optimized
- if not, we need another bit, for wrapper sharing policy, per script filename (but not object) as opposed to a fast has-system-principals test
- JS_FlagScriptFilenamePrefix can take a flags argument
- do we want JS_UnflagScriptFilenamePrefix? do we ever unload chrome?
- the resolution:
- bsmedberg will support an xpcnativewrappers=yes option in the chrome manifest
- this will cause chrome to get the XPConnect service and call its new wantXPCNativeWrappers(filenamePrefix) method
- which will call JS_FlagScriptFilenamePrefix
- Open Issues
- bz may have --enable-extensions=all, is seeing double-auto-reg on every start (I am seeing single, separate bug)
- this leads to a restart with zero live contexts, apparently, and some prefixes are lost
- never to be re-added (although all are added at least twice)