FATAL:setuid_sandbox_host.cc(157)

[carlosnewmusic]

What version of this package are you using? 0.21 deb What operating system, Node.js, and npm version? kali linux, v12.10.0 , 6.10.3 What happened? What did you expect to happen? which will start the program normally Are you willing to submit a pull request to fix this bug? no

[mathiasvr]

Related issue https://github.com/electron/electron/issues/17972.

Seems like this should be handled in electron-installer-debian, but does not work for Electron 6?

@carlosnewmusic For now, you have to run webtorrent-desktop with the --no-sandbox flag, or run the following commands to fix permissions:

sudo chown root chrome-sandbox
chmod 4755 chrome-sandbox

[Francewhoa]

I can confirm a similar challenge with webtorrent-desktop_0.20.0-1_amd64.deb on Debian 8 Jessie

Steps to reproduce at #1705

[feross]

I'd like feedback from other collaborators on how to proceed here. It seems that downgrading to Electron 5 is one option to fix this? Is there another approach we should consider?

[hicom150]

Another approach that Microsoft's VSCode team took is to add --no-sandbox in the launch scripts (Desktop files) as we can see here.

It could be a relative easy fix until a better solution is given from electron team 😅

[feross]

That seems like a reasonable approach.

[hicom150]

If you want to reproduce this issue, you system should have kernel.unprivileged_userns_clone disabled. You can check this with the next command: sudo sysctl kernel.unprivileged_userns_clone

I'm my case, in Ubuntu 18.04.3 LTS is enabled by default so I've to disabled with sudo sysctl kernel.unprivileged_userns_clone=0 to reproduce the issue.

BTW, I just send a PR #1707 that should fix the issue, but any help checking it in your system is welcome 😉

[amithm7]

I'm using v0.24.0

This is not resolved for me:

Edit: I see that the fix done in the PR above is to add --no-sandbox to desktop file. But this doesn't allow the launch of app from browser to open a magnet link.

[Francewhoa]

I suggest to re-open this ticket. Because this zombie-error is back ;) And needs more fixing love. This is to confirm this challenge is still present with WebTorrent v0.24.0

Steps to reproduce

1. Using Terminal, as user, without Sudo permission, execute this command to open WebTorrent webtorrent-desktop

2. This error is return. This is the challenge.

   [24878:1006/111415.606303:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /usr/lib/webtorrent-desktop/chrome-sandbox is owned by root and has mode 4755. Trace/breakpoint trap

3. Expected result it WebTorrent opens without this error above, and without using the temporary workaround --no-sandbox.

Using

• Debian 10 Buster
• WebTorrent 0.24.0 (0.108.6) (x64)
• GNOME 3.22.2

A temporary workaround is to start WebTorrent with this command: webtorrent-desktop --no-sandbox

[feross]

Re-opened since it appears this is still not fixed.

[amithm7]

I'm using v0.24.0

This is not resolved for me:

Edit: I see that the fix done in the PR above is to add --no-sandbox to desktop file. But this doesn't allow the launch of app from browser to open a magnet link.

Although I am still on v0.24.0, this issue has been fixed for me.

Not sure what fixed it but I am using a new instance of the OS, i.e. Debian 11 (bullseye). Previously being on Debian 10.

Permissions on chrome-sandbox file now:

-rwsr-xr-x   1  501 staff   5811400 Aug 29  2020 chrome-sandbox

[github-actions[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?