Signal-desktop: Signal Desktop fails to start with "Trace/breakpoint trap" or "The SUID sandbox helper ... is not configured correctly"

[vtevelde]

• [X ] I have searched open and closed issues for duplicates

Bug Description

After upgrading to the latest signal-desktop-beta, 1.27.1-beta.6, the application fails to start. When running from the command line the only output is "Trace/breakpoint trap". The last couple of pages of output from "strace signal-desktop-beta" is available from https://pastebin.com/ZPTy5QFz

Steps to Reproduce

1. Upgrade signal-desktop-beta to latest version
2. Run signal-desktop-beta

Actual Result: signal dies with output "Trace/breakpoitn trap"

Expected Result: signal desktop gui opens

Signal Version: 1.27.1-beta.6

Operating System: Debian 5.2.9-2

Linked Device Version: (Not yet linked)

[kenpowers-signal]

Hi, @vtevelde. v1.27.x of Signal upgrades Electron by two major versions. The most recent version of Debian expected to work with the most recent releases of Electron is Debian 8: https://electronjs.org/docs/tutorial/support#linux

[inthewaves]

@kenpowers-signal I'm getting the same issue on Debian 10 for 1.27.1-beta.7. Running signal-desktop-beta first gave me the following error:

$ signal-desktop-beta
[22117:0823/150147.047439:FATAL:setuid_sandbox_host.cc(157)] 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 /opt/Signal Beta/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

Then I executed

$ cd /opt/Signal\ Beta/
$ sudo chown root chrome-sandbox 
$ sudo chmod 4755 chrome-sandbox 
$ signal-desktop-beta 

which only gave me the Trace/breakpoint trap error.

The only way for me to get the beta to run successfully is to do

$ signal-desktop-beta --no-sandbox

I had no problems running Signal Desktop 1.26.2

[scottnonnenberg-signal]

Looks like we're running into this bug: https://github.com/electron/electron/issues/17972

Seems that the affected linux distro have disabled unprivileged access to CLONE_NEWUSER in the kernel. From the issue "Some kernels support changing this with sysctl kernel.unprivileged_userns_clone=1"

[vtevelde]

Thanks @kenpowers-signal . I should have also mentioned that I had exactly the same issue as @inthewaves with chrome-sandbox permissions as well, but fixed it the same way.

[hexmode]

signal was supposed to be starting on login for me so I didn't notice this after a recent upgrade until I went to start it directly. I found kernel.unprivileged_userns_clone=1 via electron/electron#17972 and then wanted to report it here. This should be handled in the upgrade.

lxc handles this by creating /etc/sysctl.d/30-lxc-inotify.conf and then running sysctl --system during installation.

[lorenzhs]

This affects the stable 1.27.1 release now, which broke on upgrade for me (Debian unstable). Manually setting setuid on chrome-sandbox fixed it. The first comment on the linked Electron issue says "Apps that are distributed on Linux will need to incorporate this into their install process." I guess this should be added as a post-install hook to the Debian package.

[PtyMatt]

This affects the stable 1.27.1 release now, which broke on upgrade for me (Debian unstable). Manually setting setuid on chrome-sandbox fixed it.

Same for me with Debian 10 Buster (stable).

[abrock]

Same for me (Debian testing), this fixed it:

sudo chmod 4755 /opt/Signal/chrome-sandbox

[eighthave]

I'm also affected by this on Debian 10/buster/stable, I just updated to _signal-desktop_ v1.27.1.

There is no way I'd do _setuid_ for an app. sudo sysctl kernel.unprivileged_userns_clone=1 worked for me as a temporary workaround.

[scottnonnenberg-signal]

Everyone - please try out v1.27.2-beta.1, just released. It adds a --no-sandbox to the .desktop file put on disk, which should avoid this problem without the need for a _setuid_ or change via sysctl.

Beta install instructions are here: https://github.com/signalapp/Signal-Desktop#install-the-beta

[hexmode]

I installed v1.27.2-beta.1, disabled the sysctl mod, and made sure the setuid bit was not set, and verified that it ran with --no-sandbox.

Thanks!

[eighthave]

--no-sandbox does allow Signal to run again, but running without a sandbox sounds less than ideal. My workaround is: firejail /opt/Signal/signal-desktop --no-sandbox.

[ypossem]

I've been using the Signal release from Flathub, and the release version has just started doing this. Flathub apps are frequently advertised as being sandboxed, so I don't see how setting no sandbox would fly with this model.

[santa-klaus]

@scottnonnenberg-signal Sorry to ask, but do I understand you correctly that the solution you suggest is running signal without sandbox (i.e. adding the --no-sandbox option), allowing kernel.unprivileged_userns_clone=1 or installing and running it from firejail?

My understanding of these things is limited, but it seems like they have a security implication that might be important to discuss. I doubt that unprivileged access to CLONE_NEWUSER in the kernel got disabled without a good reason, and I don't think disabling the sandbox comes without price.

[fabrei]

Same here with debian 9.11 and signal desktop app 1.27.2. Setting the permissions as mentioned chmod 4755 /opt/Signal/chrome-sandbox, chown root /opt/Signal/chrome-sandbox and running the app with signal-desktop --no-sandbox works for me. As well as running sysctl kernel.unprivileged_userns_clone=1 first and starting signal normally without the parameter --no-sandbox.

[aknrdureegaesr]

Everyone - please try out v1.27.2-beta.1, just released. It adds a --no-sandbox to the .desktop file put on disk, which should avoid this problem without the need for a setuid or change via sysctl.

I'm calling plain signal-desktop without going through the desktop file. The problem still prevents Signal desktop from starting when I do that. This is on Debian Stretch with signal-desktop version 1.27.4.

[kenpowers-signal]

@aknrdureegaesr can you use the --no-sandbox flag to launch signal-desktop?

[aknrdureegaesr]

@aknrdureegaesr can you use the --no-sandbox flag to launch signal-desktop?

Yes, that works for me as well.

[NickEckardt]

The error shows up on my box (debian 10) as "trace trap (core dumped)". Almost opened a separate issue, hopefully this helps other find this issue.

[chaoscommander]

I have the same problem after each update on Gentoo. Doing a manual chmod 4755 /opt/Signal/chrome-sandbox fixes it. Wouldn't it be an acceptable workaround to put that into the automatic installation routine? I'd say, more so than just running without a sandbox.

[jgoerzen]

On Debian buster for quite some time now, signal-desktop fails to start after every upgrade. The error message is:

[18045:0212/102302.476860:FATAL:setuid_sandbox_host.cc(157)] 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 /opt/Signal/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

I have to manually chmod that file and then it works. Why not just set it in the .deb or in the postinst?

[lorenzhs]

It's not technically hard to fix this during packaging, but I understand the objections to shipping a setuid binary unconditionally. For chromium, Debian solves this by providing a chromium-sandbox package that is Recommend:-ed by the main chromium package and contains the setuid binary. This allows people who don't want it to either configure kernel.unprivileged_userns_clone=1 or run with --no-sandbox.

Achieving this is a matter of running chmod on the chrome-sandbox binary during the build process. There's no need to chown it (i.e., no root required for the build process) because dpkg installs packages' contents as owned by root. You might need to additionally exclude it from some further checks (dh_fixperms, lintian) and package it separately but otherwise this shouldn't be hard to integrate into the build process.

I think that would be the best solution for Signal as well, because shipping a package that doesn't start by default is clearly not a great state of affairs.

[lorenzhs]

This is fixed in v1.32.0 and the issue can be closed, I suppose.

[scottnonnenberg-signal]

@lorenzhs What behaviors have you observed, exactly?

[lorenzhs]

The postinstall script (postinst in control.tar.gz inside the debian package) now runs chmod 4755 '/opt/Signal/chrome-sandbox' || true, so it's possible to run "signal-desktop" without arguments after installation. No manual chmod, sysctl, or --no-sandbox needed. Therefore, the issue that signal won't start unless one of these three things is done is fixed (at least for users of the Debian package, I suppose).

[lorenzhs]

For a few releases now, this has been broken again: the postinst script of the Debian package no longer chmods the chrome-sandbox binary :( I don't exactly remember when this started again but it was a few releases ago.

[bill-mcgonigle]

I see that /usr/share/applications/signal-desktop.desktop includes --no-sandbox . I'm not quite sure how I've been launching signal from the command line on my other Buster desktops, but on this one /usr/bin/signal-desktop is a symlink to /opt/Signal/signal-desktop. Should /usr/bin/signal-desktop be a one-liner bash script to launch with --no-sandbox so the behavior is the same either way? This would have saved me 20 minutes just now going down wrong paths.