- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
Flash analyzes the parents of the path to its appdata folder on Windows using GetFileAttributesW. If it runs into an error, it makes some internal decisions that cause it to break DRM video. Our new sandbox hardening causes GetFileAttributesW to return an error for some components of the path. This patch alters the behavior of GetFileAttributesW so that it always reports FILE_ATTRIBUTE_DIRECTORY for any path that both 1) would otherwise return an error and 2) is an ancestor of the appdata folder. This may not always be 100% accurate (for instance, if the folder is a reparse point) but restores video functionality.
Depends on D7532
Differential Revision: https://phabricator.services.mozilla.com/D7533
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
Flash analyzes the parents of the path to its appdata folder on Windows using GetFileAttributesW. If it runs into an error, it makes some internal decisions that cause it to break DRM video. Our new sandbox hardening causes GetFileAttributesW to return an error for some components of the path. This patch alters the behavior of GetFileAttributesW so that it always reports FILE_ATTRIBUTE_DIRECTORY for any path that both 1) would otherwise return an error and 2) is an ancestor of the appdata folder. This may not always be 100% accurate (for instance, if the folder is a reparse point) but restores video functionality.
Depends on D7532
Differential Revision: https://phabricator.services.mozilla.com/D7533
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
This call gated by ifdef OS_WIN - so on Linux it would leak objects that were supposed to be ClearOnShutdown in the plugin process
--HG--
extra : rebase_source : 24c4233ec8735e0176d584b623ad626d0a9b5c3b
Replace the boolean pref "security.sandbox.mac.flash.enabled"
with "dom.ipc.plugins.sandbox-level.flash" to support sandbox
levels and be consistent with the Windows pref name.
Adds filesystem read access to the sandbox using sandbox extensions
granted by the file dialog machinery (level 1).
Add support for level 2 which blocks read access.
Allow the sandbox to be disabled with MOZ_DISABLE_NPAPI_SANDBOX.
MozReview-Commit-ID: 4rfobEoxQpF
--HG--
extra : rebase_source : 05dc54b46063967e959bc3fced21c61e5463de48
Replace the boolean pref "security.sandbox.mac.flash.enabled"
with "dom.ipc.plugins.sandbox-level.flash" to support sandbox
levels and be consistent with the Windows pref name.
Adds filesystem read access to the sandbox using sandbox extensions
granted by the file dialog machinery (level 1).
Add support for level 2 which blocks read access.
Allow the sandbox to be disabled with MOZ_DISABLE_NPAPI_SANDBOX.
MozReview-Commit-ID: 4rfobEoxQpF
--HG--
extra : rebase_source : 87f2f00867c4522ae3102abbc44fd05db63c7ec7
Removing #define XRE_DONT_PROTECT_DLL_LOAD from plugin-container.cpp and xpcshell.cpp allows the #included nsWindowsWMain.cpp to protect DLL loads much earlier in the plugin process startup.
MozReview-Commit-ID: HbgyfvljvFs
--HG--
extra : rebase_source : dccdabb2e5bee4472d5aef9400a58cb0e397c112
extra : histedit_source : da248fc6fbdf96f30979f3a0396aefcf4bfcd5d9
This code was added in bug 607832 to work around a Shockwave Player bug where it tries to load some DLLs from the current directory, but the current directory is not the one it expects. We no longer support the Shockwave Player plugin, so this workaround is no longer necessary and we can always call SetDllDirectory("") to remove the current directory from the DLL search path.
MozReview-Commit-ID: C4MjB1SkZE3
--HG--
extra : rebase_source : 6473ca88db6bee484c3c97669dca39daf31b438e
extra : histedit_source : f4abb901979b07f0aa346508773a8e65f47451cd
We have not been initializing or shutting down XPCOM in the plugin process. We need the nsThreadManager for this bug but, more importantly, we need to properly shut down XPCOM in order to get things like handlers connected to the ShutdownPhases (e.g. ClearOnShutdown, used to free resources at process end).
This patch includes some work to make services that are uninitialized in the plugin process to handle Shutdown calls without failing.
This patch has a few side effects:
1. Plugins in the chrome process are "mirrored" to all content processes,
although this mirroring is currently imperfect (bug 1090576)
2. Plugins are no longer sorted by modification date in nsPluginHost.
3. Plugin exceptions are no longer propagated to JS code. They are ignored.
