Skip to content
This repository has been archived by the owner on Aug 1, 2022. It is now read-only.

Not working on Debian 10 SUID Error #1465

Closed
stevavoliajvar opened this issue Dec 6, 2020 · 4 comments
Closed

Not working on Debian 10 SUID Error #1465

stevavoliajvar opened this issue Dec 6, 2020 · 4 comments
Labels
bug Something isn't working needs-review

Comments

@stevavoliajvar
Copy link

Hi,

I wan’t to try out radicle, downloaded app and sadly system won’t run it.
I am running Debian 10.
The error I get is this:

[7207:1205/234345.685735: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 /tmp/.mount_radiclHy5nT5/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

I cannot chmod that file, it’s like it doesn’t exist, tried with sudo and everything.

My guess is that this is some Electron problem.

Any ideas on how to fix this ?

@xla xla added bug Something isn't working infrastructure labels Dec 6, 2020
@xla xla added this to the v0.1.5 milestone Dec 6, 2020
@xla
Copy link
Contributor

xla commented Dec 6, 2020

I had the same issue on my Debian computer. I couldn’t find a “good” workaround, but running the AppImage with --no-sandbox got it to open.

@wschwab
Copy link

wschwab commented Dec 6, 2020

+1 on the issue, also on Debian. This error often comes up in Electron, I second @stevavoliajvar 's guess. I'd rather not disable the sandbox.

Update: Hmmm, I just discovered this thread about the same issue in a different AppImage, there commenters suggest running --no-sandbox isn't a security issue, at least not moreso than using Electron in the first place.

Here's another resource on the issue, the third solution should work for Debian users, though I don't know what the security ramifications are, nor are they mentioned in the article. The issue thread from Patchwork (linked above) also considered this as an option in their .deb packages, though, which gives the impression that it's not incredibly insecure, but DYOR.

@barak
Copy link

barak commented Dec 6, 2020

You can fix it like this:

$ sudo sysctl kernel.unprivileged_userns_clone=1

Don't worry it's not actually doing anything scary. It enables appimage's preferred security mechanism. If that preferred mechanism is not enabled, it falls back to the nasty old sandbox thing, which also fails with that sandbox error message.

Running with --no-sandbox totally disables security, eek, scary, this is a better solution.

@barak
Copy link

barak commented Dec 7, 2020

And do this if you want it to persist across boots:

$ echo 'kernel.unprivileged_userns_clone=1' | sudo tee --append /etc/sysctl.d/local.conf

@xla xla modified the milestones: v0.1.5, v0.1.6 Dec 8, 2020
@xla xla added the triage label Dec 13, 2020
@juliendonck juliendonck removed this from the v0.1.7 milestone Jun 21, 2021
@rudolfs rudolfs closed this as completed Aug 1, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working needs-review
Projects
None yet
Development

No branches or pull requests

8 participants