1501121 - [Mac] With sandbox early startup enabled, content processes become "Not Responding" in Activity Monitor

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect, P1)

Description

[Haik Aftandilian [:haik]]

With security.sandbox.content.mac.earlyinit=true (introduced with bug 1431441), content processes are listed as "Not Responding" in the macOS Activity Monitor. See bug 1498845 which was filed when earlyinit was previously enabled on Nightly.

This problem is due to the earlyinit=true implementation failing to call CGSShutdownServerConnections() after enabling the content sandbox. We added the call to CGSShutdownServerConnections() in bug 1481304 specifically to drop the connection to the windowserver and prevent "Not Responding" which became an issue when we removed the native event loop.

With the call to CGSShutdownServerConnections() added back, content processes were displayed normally in Activity Monitor. Tested on 10.14 and 10.11.

Comment 1

[Haik Aftandilian [:haik]]

With CGSShutdownServerConnections() added back, I've noticed that the generic application icon is no longer displayed in Activity Monitor for content processes and instead we have no icon. I did some experimenting with adding coreservices, launchservices, and distnoted to the policy, but it didn't bring the icon back. I think it's acceptable to not have the icon for child processes in Activity Monitor. CLI applications do not have icons and neither do some of the helper processes for Google Chrome and Safari.

CGSShutdownServerConnections() does have to be called after SetProcessName() which appears to be the first call made that opens the WindowServer connection. Otherwise CGSShutdownServerConnections() hangs in internal SkyLight`initDisplayState() (presumably blocked waiting for the WindowServer). Once we remove the connection to the WindowServer, we'll have to either avoid calling SetProcessName() or find an alternative implementation that doesn't depend on the WindowServer connection. Alternatively, we could just set a name in the plugin-container.app Info.plist. I'll file a bug to document this and associate it with a windowserver removal bug.

The changes add back use of the SendSetProcessSandbox() message for the earlyinit mode for the call to CGSShutdownServerConnections().

Comment 2

[Alex Gaynor [:Alex_Gaynor]]

Just wanted to confirm that yes, it hangs if you call shutdown when there are no open windowserver connections. I filed a bug with Apple on this and haven't heard anything from them about it :-)

Comment 3

[Haik Aftandilian [:haik]]

Attachment: Bug 1501121 - [Mac] With sandbox early startup enabled, content processes become "Not Responding" in Activity Monitor r?Alex_Gaynor

When early sandbox setartup is enabled, revert to sending SetProcessSandbox() to the child process as before. In the child process RecvSetProcessSandbox() handler, call CGSShutdownServerConnections() and then return early if the sandbox is already enabled.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/141e7c1fa433
[Mac] With sandbox early startup enabled, content processes become "Not Responding" in Activity Monitor r=Alex_Gaynor

Comment 5

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/141e7c1fa433

Comment 6

[Haik Aftandilian [:haik]]

(In reply to Haik Aftandilian [:haik] from comment #1)
> Once we remove the connection to the WindowServer, we'll have
> to either avoid calling SetProcessName() or find an alternative
> implementation that doesn't depend on the WindowServer connection.
> Alternatively, we could just set a name in the plugin-container.app
> Info.plist. I'll file a bug to document this and associate it with a
> windowserver removal bug.

I did some testing with security.sandbox.content.mac.earlyinit=true and security.sandbox.content.mac.disconnect-windowserver=true and found that the SetProcessName() appeared to work (as reported by Activity Monitor) and CGSShutdownServerConnections() didn't block. lsmp output showed no WindowServer. I did run into an issue on Mojave where form controls weren't rendering just like in bug 1502228. On 10.11, the form controls were OK. When we are ready to remove our connection to the WindowServer (bug 1467758), we'll have to fix this. Will file a new bug and make it block bug 1467758.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

I'm still seeing child processes show up as Not Responding in Nightly 68. Is that expected?

Comment 8

[Haik Aftandilian [:haik]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #7)

I'm still seeing child processes show up as Not Responding in Nightly 68. Is that expected?

No. Could you file a new bug?

I was only able to reproduce this after disabling the content sandbox by setting the pref security.sandbox.content.level=0 or the environment variable MOZ_DISABLE_CONTENT_SANDBOX. Do you have the content sandbox disabled? Either way, it's a bug. I will try using mozregression.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

Nope, you're right I checked and had pref security.sandbox.content.level=0. I fixed that and I'm pretty sure the problem is gone now. Thanks.