FATAL Unable to start riot 1.3.2 after upgrade

[532910]

% riot-web 
[19945:0806/110917.237662: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/Riot/chrome-sandbox is owned by root and has mode 4755.

% l /opt/Riot/chrome-sandbox 
-rwxr-xr-x 1 root root 5.0M 2019-08-05 17:15 /opt/Riot/chrome-sandbox*

% apt policy riot-web 
riot-web:
  Installed: 1.3.2
  Candidate: 1.3.2
  Version table:
 *** 1.3.2 500
        500 https://packages.riot.im/debian sid/main amd64 Packages
        100 /var/lib/dpkg/status

[jryans]

What was the version you upgraded from?

[532910]

1.3.0 IIRC

[SISheogorath]

Same problem appears on flatpak: flathub/im.riot.Riot#59

And I was able to reproduce the issue locally as well. I wonder if we can do anything to help here.

[jryans]

We did upgrade to Electron 5 as part of the recent release, so it could be related to this.

[jryans]

It seems related to this issue reported to electron-builder. I see some workarounds suggests to run Electron with --no-sandbox, but I am not sure the best to apply that. Could someone affected try some of the workarounds mentioned there?

[532910]

% riot-web --no-sandbox works

[jryans]

Looking at the related Electron issue, what about if you do:

$ sudo sysctl kernel.unprivileged_userns_clone=1

and then test running riot-web without any special sandbox options? This enables an OS feature called CLONE_NEWUSER, you can read more about it.

The above sysctl setting is the default on Ubuntu 18.04, but it may not be enabled on your distro.

[532910]

yes, it works with kernel.unprivileged_userns_clone=1. Looks like it's 0 by default on debian systems.

[jryans]

Okay, it's good to know there are several possible approaches to get Riot working. This seems to be something that would affect any app using Electron 5 or later.

We'll keep watching the Electron packaging tools for any news on the right way to bake in a workaround for this issue, but for now I would suggest using one of the workarounds mentioned above.

[aaronraimist]

@jryans see electron/electron#17972 (comment). This is intentional.

[jryans]

I understand that. It's possible the Electron packing tools may add more helpers to smooth over the situation though, and that's what we can watch out for.

[aaronraimist]

It says

You must ensure that your distributed packages to set the appropriate permissions. Most tools (at least electron-builder, electron-installer-snap, electron-installer-debian, and electron-installer-redhat) support this automatically and require no configuration from the developer.

and I believe Riot is using Electron-builder so presumably Riot is just using an old version that doesn’t have this, so we should update

[jryans]

The related electron-builder issue suggests it's only fixed for snaps, so the full status is unclear. But anyway, it's something to try.

[gerroon]

I have the same issue with Debian Repo and Flatpak installs

riot-web 
[25601:0806/091123.244387: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/Riot/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

[croulibri]

I face exactly the same situation as @gerroon !

[SISheogorath]

@croulibri For Flathub I decided to rollback to 1.3.0 until we found a usable solution, I'll experiment with the disabled sandbox. It's a general hot topic that various electron apps are facing right now.

[quazgar]

Would this work as a workaround?

sudo chmod +s /opt/Riot/chrome-sandbox

[gerroon]

@ quazgar that would not work for the Flathub install.

[t3chguy]

@gerg5c42g542g2c54g52c because the workaround has to be implemented in electron-builder
No way to implement it at the riot level without forking electron builder

[croulibri]

On Debian Buster, with Riot from Riot repository, doing
sudo sysctl kernel.unprivileged_userns_clone=1
solves the problem.
The upgrade to 1.3.2. works.

Thanks @jryans

[croulibri]

But I have to do
sudo sysctl kernel.unprivileged_userns_clone=1
after every reboot :-(
I there a more sustainable way?

[jryans]

You can make it persist across reboots by editing /etc/sysctl.conf.

[abeluck]

So without the hacky sysctl workaround, riot-web is broken on Debian right now?

Just rebooted and discovered I couldn't open riot :/

[jryans]

As I understand it, this would affect any application using Electron 5 or later.

[jryans]

As a summary of the current state, on distros like Debian which disable CLONE_NEWUSER for unprivileged users, there are two possible workarounds:

1. You can decide to trust the user namespacing API and allow it for unprivileged users via sudo sysctl kernel.unprivileged_userns_clone=1 and / or persisting in /etc/sysctl.conf
2. You can decide to trust the Electron distributed with Riot only by running sudo chmod 4755 /opt/Riot/chrome-sandbox

Trusting a specific app (2) instead of an entire API (1) seems like a smaller trust surface. It looks like the Chrome team considers considers user namespaces to be the modern way forward, but if some key distros like Debian disagree, then applications are sort of stuck in the middle like this.

[jryans]

I think I see a path forward by tweaking electron-builder... Let's see how it takes. 😅

[jryans]

Riot now includes the SUID approach on develop, and it will be included in the next release.

[jryans]

This has now been released as Riot 1.3.3 for Linux only.

[jryans]

5064 -rwsr-xr-x 1 root root 5185424 Aug 16 16:32 /opt/Riot/chrome-sandbox

Yes, I believe that looks correct.