Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧ Reporter
	Description • 9 years ago

The Linux sandboxing build configuration is… kind of a mess.

The core sandboxing code can't be linked into libxul, because it uses the sandbox import of Chromium code and that would conflict with the IPC Chromium code.  On B2G it's used by both plugin-container and the b2g executable (which can fork and act as a content process to save memory); on desktop only plugin-container needs it, but it needs to be in the executable for reasons that are explained in bug 1088488 (and could probably be summarized in public, but I couldn't get clear guidance on what I could safely say, so I haven't).  So on B2G it's in a separate libmozsandbox.so, but on desktop it's built into plugin-container.

There are some delicate things done to deal with sandboxing being conditionally either before or after libxul in linkage order, which were annoying to write but aren't too much of an ongoing maintenance burder.

Meanwhile, the the crash reporting code in the "glue" directory uses Gecko internal interfaces, as does the filesystem broker to some extent.  So those are both in libxul in all cases.

The SandboxInfo module needs to be accessible to Gecko code in both parent and child, and to the sandbox code; also, it has state, and it would be good to avoid duplicating it and running its initializer twice.  So it's in the leafmost object that needs it: libmozsandbox on B2G and libxul on desktop.

And then there's SandboxLogging, which is used by everything else, so that's built into libxul as well as libmozsandbox (B2G) or plugin-container (desktop).  Inelegantly, SandboxInfo uses it but takes advantage of other directories' moz.build files ("glue" for libxul, toplevel for libmozsandbox) requiring it for linkage.

And *then* there's SandboxUtil.  Currently used only by the sandbox code, so built along with it, but bug 1222500 would add a dependency from SandboxInfo.  Just adding it to common/moz.build would break the B2G build, because it's in libmozsandbox there and that already has a copy of SandboxUtil.

But it's worse than that, because of the gtests: libxul-gtest includes SandboxUtil in order to test it, as well as SandboxBrokerClient (normally part of the sandbox core) likewise, as well as the normal contents of libxul.  This means that handling bug 1222500 with a platform-conditional addition to SOURCES *still* breaks the build, because libxul-gtest doesn't link.

This means that the least bad approach to bug 1222500 is either to copypaste the function I need, which is generally a bad idea, or to treat SandboxUtil like SandboxLogging even though nothing in glue/ actually uses it.

So, *something* in here needs fixed.  Maybe there need to be a lot more subdirectories so that these dependencies can be specified explicitly as USE_LIBS and deduplicated.  But until then, I want a bug number so I can comment the workarounds, and I want the situation and rationale spelled out so that the person who looks at this doesn't need to be me.