The SUID sandbox helper binary was found, but is not configured correctly #17972
Comments
|
Unfortunately there's no way we can configure this correctly automatically, because setting the appropriate permissions requires root privileges and we don't want to ask for a root password during Ideally, Arch would configure its kernel support unprivileged CLONE_NEWUSER and Chromium (and Electron) could use the namespace sandbox instead of relying on the old setuid sandbox. Apps that are distributed on Linux will need to incorporate this into their install process. See electron-userland/electron-installer-debian#184 and electron-userland/electron-installer-redhat#112 for example. During development, we should probably print something out on |
|
Hey, thanks for the super quick response! Does unprivileged CLONE_NEWUSER come from Please let me know if there's anything I can do to help, or if this is expected output on Arch I'm happy to close -- I understand that there's some jankiness to be expected when running bleeding-edge distros and I don't mind resolving this in a |
|
|
|
Is there a possible workaround in the meantime until every linux distro enables those features? |
|
@kitingChris The setuid sandbox IS the workaround. You just need to ensure that when developing / releasing an electron app your dev / packaging scripts set the permissions of the sandbox helper correctly as @nornagon linked above. |
See the original message:
Also see here #16631 (comment) So to make suid sandbox work you basically have to tweak the
The issue is more severe though if running appimage/snap packages, I have not yet revealed a decent workaround for these cases. It's working if appimage is executed with |
Executing |
I confirm executing |
|
@vladimiry I needed to first chown and then chmod. The other way round it didn't work. |
|
@burningTyger you are right, I just have changed the original message. |
|
@nornagon If we |
* SUID sandbox related, see electron/electron#17972
|
same here is bad new fonction for what need to change that... :( |
* SUID sandbox related, see electron/electron#17972
|
@MarshallOfSound zip does not support permissions, but ultimately the issue is not the chmod permission, but rather the owner. The setuid sandbox helper is suid to root, because it needs to perform functions that are only available to root. If it were possible to set the appropriate permissions without first gaining root privileges, that would be a very serious vulnerability in Linux. Fortunately for Linux, and unfortunately for us, that is not the case. Here are the options as I see them:
I'm leaning towards (2). It would ease development without compromising the security of the deployed app. I'm not yet sure what to do about snap/flatpak, as I'm not familiar with their workings. It's possible that they already sandbox the app sufficiently that we can disable sandboxing altogether in that situation, as we do when building the Mac App Store version of Electron. |
|
As for now, I like more the first option.
Such scenario would be somehow misleading. One might be successfully running unpackaged app without sandboxing, but there is a chance that the packaged app won't work the same way with enabled sandboxing. Like, for example, the case when you access the main process from the renderer process not through the
So a packaged app that was designed and developed as sandboxed might be executed without sandbox if no sandbox available. This doesn't sound good to me.
What does it mean exactly? What would be the way to enable sandboxing on Linux in the way the app either starts or fails if no sandboxing available (the current situation, forced sandboxing). |
|
I also like (1), but to defend (2) a little, the API exposed to the app wouldn't change when disabling the sandbox. The only thing we would disable is the OS-level sandbox. We would still load the app the same way, it just wouldn't be protected by the OS. |
Then it sounds good to me too. Thanks for the explanation. |
I am able to reproduce this on Ubuntu 24 ARM. > The SUID sandbox helper binary was found, but is not configured correctly. See: - electron/electron#17972 - https://stackoverflow.com/questions/63780918/building-electron-linux-distro-the-suid-sandbox-helper-binary-was-found-but-i
…#1695) I am able to reproduce this on Ubuntu 24 ARM. > The SUID sandbox helper binary was found, but is not configured correctly. See: - electron/electron#17972 - https://stackoverflow.com/questions/63780918/building-electron-linux-distro-the-suid-sandbox-helper-binary-was-found-but-i
From toeverything/AFFiNE#6722 (comment) > Disable sandboxing entirely by launching with --no-sandbox. Adding this argument from JS is unfortunately insufficient, as the GPU process is launched before the main process JS is run. Ref: * electron/electron#17972
Operating System Ubuntu 24.04.1 LTS Github ubuntu-latest has points to 24.04.1 actions/runner-images#10636 (comment) related possible fix electron/electron#17972 (comment)
Operating System Ubuntu 24.04.1 LTS Github ubuntu-latest now points to 24.04.1 actions/runner-images#10636 (comment) related possible fix electron/electron#17972 (comment)
experiencing this same issue (Ubuntu 24 LTS) with the latest release of fiddle. this is the only/latest conversation I've heard about this issue. This fixed it. |
|
This just started again, and See https://github.com/filecoin-station/desktop/pull/1970/files#diff-b803fcb7f17ed9235f1e5cb1fcd2f5d3b2838429d4368ae4c57ce4436577f03fR42 and the resulting failure in https://github.com/filecoin-station/desktop/actions/runs/12372222440/job/34529950284?pr=1970: This time, fixing the |
|
You can execute without sandbox, in the "scripts": {
"start": "electron --no-sandbox ."
},Or add the parameter from javascript enrtypoint: const { app, BrowserWindow } = require('electron');
// Need root permissions or can disable sandboxing
app.commandLine.appendSwitch('no-sandbox');
const createWindow = () => {The electron package comes with the sandbox enabled by default unless you disable it manually, the problem is that to be enabled you always need root privileges, it would be better if by default it comes with the sandboxing disabled until someone wants to enable it manually and has these privileges. It is difficult to ask all users of an app to always have elevated privileges to run a calculator or a notepad. |
Removes the --no-sandbox flag from the launcher and instead adds logic to the postinst script to set the correct owner (root) and permissions (4755) for the chrome-sandbox binary. This allows the SUID sandbox to function correctly, resolving the login issue. See: electron/electron#17972
Preflight Checklist
Issue Details
Expected Behavior
Running
node_modules/.bin/electron --versionshould outputv5.0.0.To be clear, all commands create this error, but I'm using the
--versionflag for simplicity.Actual Behavior
Additional Information
If I
chownandchmodthe file then it works fine, but my intuition is thatnpm install electron@latestshould work without those commands. Is this expected behavior?The text was updated successfully, but these errors were encountered: