Need a way to run with --no-sandbox by default

[burtonator]

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

5.0 implemented sandbox by default but a ton of our users are reporting issues.

See:

https://github.com/burtonator/polar-bookshelf/issues/947
https://github.com/burtonator/polar-bookshelf/issues/891

For a stack traces and other errors.

It looks like --no-sandbox fixes it but if I construct the browser window with sandbox: false that doesn't fix the problem.

Proposed Solution

Some way to disable the sandbox by default and/or restore the old behavior.

[MarshallOfSound]

This is not something that would be easy to support, or something that is good for the security of the Electron ecosystem as a whole. The decision was made and discussed in #15760.

Any issues users are having with the SUID sandbox on linux can be fixed by either correctly configuring the OS or ensuring the permissions of the chrome_sandbox binary are correct at install time.

I'd recommend reading through #17972

For snapcraft issues, this PR to the snapcraft maker should handle those: electron-userland/electron-installer-snap#22

The stack trace in https://github.com/burtonator/polar-bookshelf/issues/947 looks like it might be a separate issue though, so raising that as a new issue would be helpful. In particular any information about any PPAPI plugins in use, or things like trying to use the chrome PDF viewer.

[jarek-foksa]

@MarshallOfSound Since there is already --no-sandbox command line argument, why not expose corresponding programmatic option? You could deprecate both of them after all critical bugs are fixed. Note that sandbox is also causing crashes on macOS: #19626.

[MarshallOfSound]

why not expose corresponding programmatic option?

Because that's not possible, the choice on what and how to sandbox is done way before a users app code ever runs. A programatic option to disable sandbox is useless

[adomyaty55foundry]

This is rediculous, I'm forced to downgrade from Electron 5.0 because of no solutions when on WSL > Cypress 3.5 which forces Electron use 5.0. Have to downgrade to 3.4. Now I'm on the older 2.0 electron just to make my tests to work

FYI this is problematic on WSL as well... All WSL users who uses the new Cypress.io 3.5 will run into this issue with NO WORKAROUND at all.

[12264:1029/152011.865024:FATAL:gpu_data_manager_impl_private.cc(892)] The display compositor is frequently crashing. Goodbye.

[vn971]

Is it also possible to have an environment variable override, in situations where directly plugging into CLI is not possible?

[vn971]

It might be useful if the electron app itself is run in another jail that disables root user (and thus SUID), and also gives access control on user-specific directories (something that is not possible to do for the app itself).

[tarruda]

Since there is already --no-sandbox command line argument, why not expose corresponding programmatic option?

The following seems to work for me:

// run this at early startup, before app.on('ready')
app.commandLine.appendSwitch('--no-sandbox')

[RobbieTheWagner]

I've been searching for a solution to the snapcraft sandbox issues for many hours now. I see that electron-userland/electron-installer-snap#22 was implemented, but I don't understand how it fixes the issue. My snap builds still all get rejected during automatic review with

human review required due to 'deny-connection' constraint (interface attributes). If using a chromium webview, you can disable the internal sandbox (eg, use --no-sandbox) and remove the 'allow-sandbox' attribute instead. For QtWebEngine webviews, export QTWEBENGINE_DISABLE_SANDBOX=1 to disable its internal sandbox. declaration-snap-v2_plugs_connection (browser-sandbox, browser-support)

How are we supposed to fix this issue?

[probonopd]

There should be an environment variable in addition to the --no-sandbox argument, doing the same thing. This would greatly simplify it to disable the sandbox globally on a system for all applications.

Use cases:

• AppImage (those can't carry setuid binaries) on systems that don't have kernel.unprivileged_userns_clone = 1 set (e.g., Debian) (a never ending source of trouble)
• FreeBSD Linuxulator (seemingly can't deal with the sandbox)
• Users running their own sandboxes (e.g., Firejail)

[rap2hpoutre]

@tarruda Is there a way to add this option only for Linux (and not for other builds ?)

[nqnp24]

@tarruda Is there a way to add this option only for Linux (and not for other builds ?)

if (process.platform === "linux") app.commandLine.appendSwitch("no-sandbox");

[jespertheend]

I want to publish an electron app to Steam, and when launched through the Steam Linux Runtime, it takes a good minute or two before either closes or shows a blank screen. The only fix I've found is to set the --no-sandbox flag.

I tried both app.commandLine.appendSwitch("no-sandbox"); and app.commandLine.appendSwitch('--no-sandbox') but neither of these seem to work.
My guess is that this switch only disables the sandbox for the render process. Whereas actually providing it on startup disables it it for everything.

If this is true, afaik you can already achieve this using sandbox: false in your webPreferences, no need to use commandLine.appendSwitch() then:

const win = new BrowserWindow({
  webPreferences: {
    sandbox: false,
  },
})

On another note, this comment mentions:

appending the switch within the app no longer works

So it's also possible that commandLine.appendSwitch() used to work at some point, but now it no longer does.

[vn971]

@jbool24 there are reasons. Also, please really do read the thread before posting a reply. I hope both of our comments would be hidden as offtopic and/or deleted to not pollute the thread.