Introduce content_nacl_nonsfi.gyp for nacl_helper_nonsfi.

Introduce content_nacl_nonsfi.gyp for nacl_helper_nonsfi.

This CL builds a library containing only SendZygoteChildPing(),
which will be used nacl_helper_linux even without the sandbox.
The lib will contain more code for sandbox implementation
in a following CL.

BUG=358465
TEST=Ran trybot.

Committed: https://crrev.com/1f29fe389bc450db6718fb424599c2945467cb9c
Cr-Commit-Position: refs/heads/master@{#303438}

[hidehiko, 2014-10-30 12:29:23]

hidehiko@chromium.org changed reviewers:
+ jam@chromium.org, jln@chromium.org, mseaborn@chromium.org

[hidehiko, 2014-10-30 12:29:24]

mseaborn@, could you review this from the project point of view?
First, I thought this is not needed for nacl_helper_nonsfi without sandbox, but
it turned out actually I need this.
I'll add more code for sandbox, so adding the .gyp file now is fine I believe,
although what I need is only one function.

jln@, could you review this as a sandbox related code OWNER?
jam@, could you review this as an OWNER of the content/?

Thank you for review in advance,
- hidehiko

[jam, 2014-10-30 22:45:48]

https://codereview.chromium.org/687363004/diff/1/content/common/child_process...
File content/common/child_process_sandbox_support_impl_linux.cc (right):

https://codereview.chromium.org/687363004/diff/1/content/common/child_process...
content/common/child_process_sandbox_support_impl_linux.cc:213: bool
SendZygoteChildPing(int fd) {
why not move this to a separate file?

[hidehiko, 2014-10-31 07:03:39]

Thank you for review. PTAL.

https://codereview.chromium.org/687363004/diff/1/content/common/child_process...
File content/common/child_process_sandbox_support_impl_linux.cc (right):

https://codereview.chromium.org/687363004/diff/1/content/common/child_process...
content/common/child_process_sandbox_support_impl_linux.cc:213: bool
SendZygoteChildPing(int fd) {
On 2014/10/30 22:45:48, jam wrote:
> why not move this to a separate file?

Done.

https://codereview.chromium.org/687363004/diff/40001/content/content_common.gypi
File content/content_common.gypi (right):

https://codereview.chromium.org/687363004/diff/40001/content/content_common.g...
content/content_common.gypi:75: 'public/common/main_function_params.h',
FYI: sorted in lexicographical order.

[jam, 2014-10-31 20:08:35]

lgtm

[hidehiko, 2014-11-03 13:31:30]

On 2014/10/31 20:08:35, jam wrote:
> lgtm

Thank you for review.
Mark, Julien, friendly ping?

Thanks,
- hidehiko

[hidehiko, 2014-11-06 04:59:29]

On 2014/11/03 13:31:30, hidehiko wrote:
> On 2014/10/31 20:08:35, jam wrote:
> > lgtm
> 
> Thank you for review.
> Mark, Julien, friendly ping?
> 
> Thanks,
> - hidehiko

Friendly, ping?

[Mark Seaborn, 2014-11-06 16:59:30]

LGTM

[hidehiko, 2014-11-10 06:30:20]

On 2014/11/06 16:59:30, Mark Seaborn wrote:
> LGTM

Thank you for review. Julien, friendly ping?

[jln (very slow on Chromium), 2014-11-10 08:51:30]

lgtm, but FYI, if it starts becoming a burden, we could move some of the
sandbox-related code needed by NaCl out of content.

For NaCl NonSFI, we don't really need content/ to initialize the BPF sandbox
since we don't inherit from content/'s "baseline policy".

If you look at what NonSFI NaCl needs, it's extremely basic:

content::SandboxSeccompBPF::StartSandboxWithExternalPolicy() which has very few
dependencies that actually live in content/.

It still makes sense to keep this in content because that is where the knowledge
of flags to enable / disable the sandbox live.

But keep in mind that if this starts introducing too much complexity, we could
move a lot of this to sandbox/ instead.

[hidehiko, 2014-11-10 09:04:20]

Thank you for review. And submitting.

On 2014/11/10 08:51:30, jln (Tokyo til 14th) wrote:
> lgtm, but FYI, if it starts becoming a burden, we could move some of the
> sandbox-related code needed by NaCl out of content.
> 
> For NaCl NonSFI, we don't really need content/ to initialize the BPF sandbox
> since we don't inherit from content/'s "baseline policy".
> 
> If you look at what NonSFI NaCl needs, it's extremely basic:
> 
> content::SandboxSeccompBPF::StartSandboxWithExternalPolicy() which has very
few
> dependencies that actually live in content/.
> 
> It still makes sense to keep this in content because that is where the
knowledge
> of flags to enable / disable the sandbox live.
> 
> But keep in mind that if this starts introducing too much complexity, we could
> move a lot of this to sandbox/ instead.

Thank you for advice.
I'll check it the code location. Let's discuss it later, while you're in Tokyo.
- hidehiko

[hidehiko, 2014-11-10 09:04:26]

The CQ bit was checked by hidehiko@chromium.org

[commit-bot: I haz the power, 2014-11-10 09:05:39]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/687363004/40001

[commit-bot: I haz the power, 2014-11-10 09:55:34]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2014-11-10 09:56:26]

Patchset 3 (id:??) landed as
https://crrev.com/1f29fe389bc450db6718fb424599c2945467cb9c
Cr-Commit-Position: refs/heads/master@{#303438}