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

Back to Bug 1506495 Comment 21