New issue
Advanced search Search tips

Issue 621792 link

Starred by 1 user
Status: WontFix
Owner:
rsesek@chromium.org
Closed: Jun 2016
Cc:
jsc...@chromium.org
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Security



Sign in to add a comment

why create sandbox when NoSandbox

Reported by pxinc...@gmail.com, Jun 21 2016 
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36

Steps to reproduce the problem:
When user disable nosandbox for  performance or etc,
RendererBlinkPlatformImpl and PpapiBlinkPlatformImpl still create sandbox object . 
getFallbackFontForCharacter and getWebFontRenderStyleForStrike will still need IPC to browser .

What is the expected behavior?

What went wrong?
I think that it should 
bool RendererBlinkPlatformImpl::sandboxEnabled() {
  if(base::CommandLine::ForCurrentProcess()->HasSwitch(
      switches::kSingleProcess))
      return false;
  if(base::CommandLine::ForCurrentProcess()->HasSwitch(
      switches::kNoSandbox))
      return false;
   return true;
}

Did this work before? N/A 

Chrome version: 51.0.2704.84  Channel: n/a
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 21.0 r0

Comment 1 by dominickn@chromium.org, Jun 21 2016

Cc: jsc...@chromium.org
Owner: rsesek@chromium.org
I believe the primary reason for this is to ensure that as little code as possible does different things when there is or isn't a sandbox in use. That increases the complexity of the code for no good reason, since we don't recommend using Chromium without the sandbox. Hence the comment in that method:

  // As explained in Platform.h, this function is used to decide
  // whether to allow file system operations to come out of WebKit or not.
  // ***Even if the sandbox is disabled, there's no reason why the code should
  // act any differently...unless we're in single process mode.  In which
  // case, we have no other choice.***  Platform.h discourages using
  // this switch unless absolutely necessary, so hopefully we won't end up
  // with too many code paths being different in single-process mode.

+rsesek, +jschuh for confirmation

Comment 2 by pxinc...@gmail.com, Jun 22 2016 

@rsesek , Do you mean that it is for code complexity.
If according by my motifition , in fact it should be no problem ?
Am i right ?

Comment 3 by rsesek@chromium.org, Jun 22 2016

Labels: -Restrict-View-SecurityTeam
Status: WontFix (was: Unconfirmed)
The expected behavior is to not run with --no-sandbox in a production environment.

That flag exists solely to debug issues with the sandbox, and so it does not deviate from the normal, sandboxed codepaths where possible.
Project Member

Comment 4 by sheriffbot@chromium.org, Oct 1 2016 

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 5 by sheriffbot@chromium.org, Oct 2 2016 

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 6 by mbarbe...@chromium.org, Oct 2 2016

Labels: allpublic
►

Sign in to add a comment