When the pref gfx.color_management.display_profile is used to load a color profile from the given path, the file is read from the filesystem in GetCMSOutputProfileData(). Before build 65, where we changed the Mac content sandbox to start earlier, GetCMSOutputProfileData() was run in content processes during startup before the content sandbox was enabled. With build 65, the sandbox is started earlier and, as a result, at the time GetCMSOutputProfileData() executes, sandbox filesystem restrictions are already enabled and prevent reading from /Library/ColorSync/Profiles. GetCMSOutputProfileData() is called in content processes during the handling of the SetXPCOMProcessAttributes message sent from the parent. As a low risk solution, we can whitelist /Library/ColorSync/Profiles and ~/Library/ColorSync/Profiles in the content process sandbox. This will mean that, on Mac, gfx.color_management.display_profile should only be set to a profile that resides in one of /Library/ColorSync/Profiles ~/Library/ColorSync/Profiles /System/Library/ColorSync/Profiles As a follow-up, we should whitelist the contents of the gfx.color_management.display_profile pref allowing color profiles to be used from anywhere on the filesystem that the user has access to. I will file a new bug to accomplish that. Content process stack trace of GetCMSOutputProfileData(): * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0 XUL`gfxPlatform::GetCMSOutputProfileData() at gfxPlatform.cpp:2112 frame #1 XUL`gfxPlatform::CreateCMSOutputProfile() at gfxPlatform.cpp:2138 frame #2 XUL`gfxPlatform::Init() at gfxPlatform.cpp:1026 frame #3 XUL`gfxPlatform::InitChild() at gfxPlatform.cpp:511 frame #4 XUL`mozilla::dom::ContentChild::InitGraphicsDeviceData() at ContentChild.cpp:1159 frame #5 XUL`mozilla::dom::ContentChild::RecvSetXPCOMProcessAttributes() at ContentChild.cpp:598 frame #6 XUL`mozilla::dom::PContentChild::OnMessageReceived() at PContentChild.cpp:7750 frame #7 XUL`mozilla::dom::ContentChild::OnMessageReceived() at ContentChild.cpp:3558 frame #8 XUL`mozilla::ipc::MessageChannel::DispatchAsyncMessage() at MessageChannel.cpp:2160 frame #9 XUL`mozilla::ipc::MessageChannel::DispatchMessage() at MessageChannel.cpp:2087 frame #10 XUL`mozilla::ipc::MessageChannel::RunMessage() at MessageChannel.cpp:1936 frame #11 XUL`mozilla::ipc::MessageChannel::MessageTask::Run() at MessageChannel.cpp:1967 frame #12 XUL`nsThread::ProcessNextEvent() at nsThread.cpp:1161 frame #13 XUL`NS_ProcessNextEvent() at nsThreadUtils.cpp:474 frame #14 XUL`mozilla::ipc::MessagePump::Run() at MessagePump.cpp:88 frame #15 XUL`mozilla::ipc::MessagePumpForChildProcess::Run() at MessagePump.cpp:271 frame #16 XUL`MessageLoop::RunInternal() at message_loop.cc:315 frame #17 XUL`MessageLoop::RunHandler() at message_loop.cc:308 frame #18 XUL`MessageLoop::Run() at message_loop.cc:290 frame #19 XUL`nsBaseAppShell::Run() at nsBaseAppShell.cpp:137 frame #20 XUL`nsAppShell::Run() at nsAppShell.mm:702 frame #21 XUL`XRE_RunAppShell() at nsEmbedFunctions.cpp:908 frame #22 XUL`mozilla::ipc::MessagePumpForChildProcess::Run() at MessagePump.cpp:238 frame #23 XUL`MessageLoop::RunInternal() at message_loop.cc:315 frame #24 XUL`MessageLoop::RunHandler() at message_loop.cc:308 frame #25 XUL`MessageLoop::Run() at message_loop.cc:290 frame #26 XUL`XRE_InitChildProcess() at nsEmbedFunctions.cpp:746 frame #27 XUL`mozilla::BootstrapImpl::XRE_InitChildProcess() at Bootstrap.cpp:61 frame #28 plugin-container`content_process_main() at plugin-container.cpp:49 frame #29 plugin-container`main() at MozillaRuntimeMain.cpp:23 frame #30 libdyld.dylib`start()
Bug 1506495 Comment 21 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
When the pref gfx.color_management.display_profile is used to load a color profile from the given path, the file is read from the filesystem in GetCMSOutputProfileData(). Before build 65, where we changed the Mac content sandbox to start earlier, GetCMSOutputProfileData() was run in content processes during startup before the content sandbox was enabled. With build 65, the sandbox is started earlier and, as a result, at the time GetCMSOutputProfileData() executes, sandbox filesystem restrictions are already enabled and prevent reading from /Library/ColorSync/Profiles. GetCMSOutputProfileData() is called in content processes during the handling of the SetXPCOMProcessAttributes message sent from the parent. As a low risk solution, we can whitelist /Library/ColorSync/Profiles and ~/Library/ColorSync/Profiles in the content process sandbox. This will mean that, on Mac, gfx.color_management.display_profile should only be set to a profile that resides in one of /Library/ColorSync/Profiles ~/Library/ColorSync/Profiles /System/Library/ColorSync/Profiles As a follow-up, we should whitelist the contents of the gfx.color_management.display_profile pref allowing color profiles to be used from anywhere on the filesystem that the user has access to. I will file a new bug to accomplish that. Content process stack trace of GetCMSOutputProfileData(): * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0 XUL`gfxPlatform::GetCMSOutputProfileData() at gfxPlatform.cpp:2112 frame #1 XUL`gfxPlatform::CreateCMSOutputProfile() at gfxPlatform.cpp:2138 frame #2 XUL`gfxPlatform::Init() at gfxPlatform.cpp:1026 frame #3 XUL`gfxPlatform::InitChild() at gfxPlatform.cpp:511 frame #4 XUL`mozilla::dom::ContentChild::InitGraphicsDeviceData() at ContentChild.cpp:1159 frame #5 XUL`mozilla::dom::ContentChild::RecvSetXPCOMProcessAttributes() at ContentChild.cpp:598 frame #6 XUL`mozilla::dom::PContentChild::OnMessageReceived() at PContentChild.cpp:7750 frame #7 XUL`mozilla::dom::ContentChild::OnMessageReceived() at ContentChild.cpp:3558 frame #8 XUL`mozilla::ipc::MessageChannel::DispatchAsyncMessage() at MessageChannel.cpp:2160 frame #9 XUL`mozilla::ipc::MessageChannel::DispatchMessage() at MessageChannel.cpp:2087 frame #10 XUL`mozilla::ipc::MessageChannel::RunMessage() at MessageChannel.cpp:1936 frame #11 XUL`mozilla::ipc::MessageChannel::MessageTask::Run() at MessageChannel.cpp:1967 frame #12 XUL`nsThread::ProcessNextEvent() at nsThread.cpp:1161 frame #13 XUL`NS_ProcessNextEvent() at nsThreadUtils.cpp:474 frame #14 XUL`mozilla::ipc::MessagePump::Run() at MessagePump.cpp:88 frame #15 XUL`mozilla::ipc::MessagePumpForChildProcess::Run() at MessagePump.cpp:271 frame #16 XUL`MessageLoop::RunInternal() at message_loop.cc:315 frame #17 XUL`MessageLoop::RunHandler() at message_loop.cc:308 frame #18 XUL`MessageLoop::Run() at message_loop.cc:290 frame #19 XUL`nsBaseAppShell::Run() at nsBaseAppShell.cpp:137 frame #20 XUL`nsAppShell::Run() at nsAppShell.mm:702 frame #21 XUL`XRE_RunAppShell() at nsEmbedFunctions.cpp:908 frame #22 XUL`mozilla::ipc::MessagePumpForChildProcess::Run() at MessagePump.cpp:238 frame #23 XUL`MessageLoop::RunInternal() at message_loop.cc:315 frame #24 XUL`MessageLoop::RunHandler() at message_loop.cc:308 frame #25 XUL`MessageLoop::Run() at message_loop.cc:290 frame #26 XUL`XRE_InitChildProcess() at nsEmbedFunctions.cpp:746 frame #27 XUL`mozilla::BootstrapImpl::XRE_InitChildProcess() at Bootstrap.cpp:61 frame #28 plugin-container`content_process_main() at plugin-container.cpp:49 frame #29 plugin-container`main() at MozillaRuntimeMain.cpp:23 frame #30 libdyld.dylib`start()