Long-term, we should avoid giving content processes way to exhaust storage space, at least on B2G. Interfaces like GC/CC logging (bug 973090) are less bad, because the parent process has to do something that users normally don't do. More of a problem are things like OpenAnonymousTemporaryFile (bug 965724), where the child can initiate the request. Generally this is replacing code that was opening files directly (e.g., MediaCache, libjar, the profiler), so it's not making the problem any worse, but it's mostly not improving on it. There's also a question of whether there exists a reasonable alternative in all cases; e.g., if MediaCache has to take data it got from the parent over PNecko and then send it back to the parent for writing, and then read it back from a read-only memory mapping, is that too much overhead? Assuming this is doable, it will be another instance of sandboxing whack-a-mole — each subsystem that uses an IPC interface that lets the child request a writable file descriptor will have to be adapted to not do that, while we try not to add more. It would be possible to make ipc::FileDescriptor reject writable descriptors for regular files (at least on Unix), and use a separate class for a descriptor that can/will be one of those, so that the IPDL is explicit about where this can happen. It's not yet clear if this would be worth the effort and the code complication.

One useful property of OpenAnonymousTemporaryFile: if the process holding the descriptors exits, then the disk space will be reclaimed. On B2G, closing the app will do this; on B2G or desktop, restarting the browser or rebooting will do that. In particular, it shouldn't allow causing a phone to get stuck in a reboot loop. The patch I proposed for the profiler would not have this property, so that's a reason not to do it that way.

(In reply to Jed Davis [:jld] from comment #1) > One useful property of OpenAnonymousTemporaryFile: if the process holding > the descriptors exits, then the disk space will be reclaimed. Ahem. If *all* processes holding a descriptor for the file exit. Can the child process cause the parent to hold a chosen file descriptor for arbitrarily long, either with a message that's actually defined in IPDL or with any unintended features of lower-level IPC?

(In reply to Jed Davis [:jld] from comment #2) > Ahem. If *all* processes holding a descriptor for the file exit. Can the > child process cause the parent to hold a chosen file descriptor for > arbitrarily long, either with a message that's actually defined in IPDL or > with any unintended features of lower-level IPC? For B2G, also consider the question above applied to any service exposed over the Android Binder system, which can apparently pass file descriptors, and to which content processes currently depend on having direct access.

On Linux 3.17 and up, it's apparently possible to use file seals to obtain a file descriptor that can be written but not increased in size; see F_SEAL_GROW in http://man7.org/linux/man-pages/man2/fcntl.2.html