XPConnect:Security:XPCNativeWrapper Automation

From MozillaWiki
Jump to: navigation, search

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
  • 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)