The one oddity with kill() is PulseAudio's use of POSIX shared memory: it considers each segment to have an owning process, whose pid is written to the segment, and any PulseAudio client will try to clean up segments owned by processes that no longer exist, using the traditional approach of `kill(pid, 0)`. If we returned success or ESRCH, it would delete everything and, apparently, break all use of PulseAudio enough to require a manual restart of the daemon. But if we return any other error, it deletes nothing. Because we start a PulseAudio instance before sandboxing, cleanup should still happen if needed, even if no other audio applications are used. Nothing that happens on Try uses kill() with a non-zero signal, so that can just be blocked. This doesn't exactly block bug 1328896, but it's a little silly to worry about kill()-equivalent functionality when we're still allowing actual kill().

Comment on attachment 8905682 [details] Bug 1397753 - Disallow kill() in sandboxed content processes. https://reviewboard.mozilla.org/r/177476/#review184312

Pushed by jedavis@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/40e071f08bf6 Disallow kill() in sandboxed content processes. r=gcp