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

Appimage needs --no-sandbox set during build in order to start (Solved) #1524

Open
danrobi11 opened this issue Mar 17, 2020 · 15 comments
Open

Comments

@danrobi11
Copy link

danrobi11 commented Mar 17, 2020

Running MX Linux here. The appimage 0.8.9 and 0.8.10 both wont launch. Only the appimage 0.8.8 is working. Issue might be related with MX Linux using systemd-shim? https://mxlinux.org/blog/about-mx-19-and-systemd/
Appimage v0.8.10 does work on LinuxLite which have full systemd
OS: MX x86_64
Kernel: 4.19.0-6-amd64
DE: Xfce

OS: Linux Lite 4.8 x86_64
Kernel: 4.15.0-88-generic
DE: Xfce

New edit(Solved): Found this command line: sudo sysctl kernel.unprivileged_userns_clone=1
Run the command line in terminal and after run the appimage. That fixed my issue here

@ghost
Copy link

ghost commented Mar 23, 2020

On elementary OS 5.1.2 hera (x86_64 Linux 5.3.0-42-generic), I can run 0.8.10 just fine. Could this be distro-specific, or perhaps something unique to your PC's installation?
My full screenfetch output is down below:

                                     emil@emil-G11CD
         eeeeeeeeeeeeeeeee           OS: elementary OS 5.1.2 hera
      eeeeeeeeeeeeeeeeeeeeeee        Kernel: x86_64 Linux 5.3.0-42-generic
    eeeee  eeeeeeeeeeee   eeeee      Uptime: 6h 30m
  eeee   eeeee       eee     eeee    Packages: 2416
 eeee   eeee          eee     eeee   Shell: bash 4.4.20
eee    eee            eee       eee  Resolution: 1920x1080
eee   eee            eee        eee  DE: GNOME 
ee    eee           eeee       eeee  WM: Mutter(Gala)
ee    eee         eeeee      eeeeee  WM Theme: elementary
ee    eee       eeeee      eeeee ee  GTK Theme: elementary [GTK2/3]
eee   eeee   eeeeee      eeeee  eee  Icon Theme: elementary
eee    eeeeeeeeee     eeeeee    eee  Font: Open Sans 9
 eeeeeeeeeeeeeeeeeeeeeeee    eeeee   CPU: Intel Core i7-6700 @ 4x 4GHz [35.0°C]
  eeeeeeee eeeeeeeeeeee      eeee    GPU: GeForce GTX 970
    eeeee                 eeeee      RAM: 4529MiB / 7887MiB
      eeeeeee         eeeeeee       
         eeeeeeeeeeeeeeeee     

@pfrazee
Copy link
Member

pfrazee commented Mar 23, 2020

Are you able to launch from the terminal and check for error output?

@danrobi11
Copy link
Author

$ ./Beaker.Browser-0.8.10.AppImage
[31586:0323/140435.815051: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 /tmp/.mount_Beakerk7tnAQ/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

@danrobi11
Copy link
Author

$ ./Beaker.Browser.0.8.9.AppImage
zenity, kdialog, Xdialog missing. Skipping /tmp/.mount_BeakerZz8HtL/AppRun.
[32103:0323/141017.263598: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 /tmp/.mount_BeakerZz8HtL/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

@pfrazee
Copy link
Member

pfrazee commented Mar 25, 2020

Oof, this is a bummer. Related issues:

Looks like neither snap or appimage can run with process sandboxing enabled. Based on https://github.com/electron-userland/electron-builder/blame/fc311995c196f1063ceb2d0bb0af61beac6038e8/packages/app-builder-lib/src/targets/snap.ts#L188 it looks like they disable the sandbox automatically for snaps but not appimage. Can anybody confirm if the beaker 0.8.10 snap works correctly?

We'll have to update the build for the appimage manually.

EDIT: just to comment on the security, basically the process-sandbox is a second layer of defense. There's a "Web Platform" sandbox by default which doesn't expose any access to the OS. The process-sandbox further isolates the browser's processes so that an exploit in the Web Platform has a harder time attacking the OS. Disabling the process-sandbox is not preferable but it does not remove the Web Platform sandbox; it removes a secondary defense.

@pfrazee pfrazee changed the title Appimage 0.8.9 and 0.8.10 wont launch Appimage needs --no-sandbox set during build in order to start Mar 25, 2020
@danrobi11
Copy link
Author

danrobi11 commented Mar 25, 2020

I just tested the snap v0.8.10 works perfectly and does sync with hashbase without having to restart beaker.

@pfrazee
Copy link
Member

pfrazee commented Mar 25, 2020

Okay interesting. It may be time to deprecate the appimage

@raphaelbastide
Copy link

raphaelbastide commented May 15, 2020

I might have a similar issue with Beaker.Browser-1.0.0-prerelease.1.AppImage on Debian.

[4554:0515/103927.209754: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 /tmp/.mount_BeakerDUCapz/chrome-sandbox is owned by root and has mode 4755.
fish: “./Beaker.Browser-0.8.10.AppImage” terminated by signal SIGTRAP (Trace or breakpoint trap)

@danrobi11 danrobi11 changed the title Appimage needs --no-sandbox set during build in order to start Appimage needs --no-sandbox set during build in order to start (Solved) May 15, 2020
@danrobi11
Copy link
Author

danrobi11 commented May 15, 2020

@raphaelbastide See my new edit(Solved) in the description. Should also work for you

@raphaelbastide
Copy link

@raphaelbastide See my new edit(Solved) in the description. Should also work for you

Works perfectly, thank you @danrobi11. Do you know what this command does?

@danrobi11
Copy link
Author

@raphaelbastide noclue. found it on the internet. nice workaround until this get fixed.
This issue is not related to beaker only, this happens to me with most appimages

@Butterfly
Copy link

@raphaelbastide noclue. found it on the internet. nice workaround until this get fixed.
This issue is not related to beaker only, this happens to me with most appimages

This is a little bit "apples and oranges", but I've had to use that when I couldn't get a browser to open as root. It would be during times I had to login as root, not just via sudo or su -. It was the only way I could access the Internet to find out how to fix whatever I'd broken with my normal user. 😆

My memory's foggy about it now, but it seems like that flag and whichever browser I was using had something to do with how the affected browser accessed whatever it needed to function. That functionality is blocked for a few programs with the possible thought process that root is supposed to get in, do some admin work, and then get out, not hang out playing around with games and the Internet, etc.

Because I'm always curious, too, I just tried a "what does the --no-sandbox flag do" search and received these two from the front page:

The sandbox is the "stealth" browsing technology. If you're not concerned with that, then, no big deal.

hm 😄

@j75
Copy link

j75 commented Jan 4, 2021

Same problem on Ubuntu 20.04 - even with --no-sandbox option it spits some warnings

[32906:0104/104101.267695:FATAL:platform_shared_memory_region_posix.cc(255)] This is frequently caused by incorrect permissions on /dev/shm.  Try 'sudo chmod 1777 /dev/shm' to fix.

(which is wrong, /dev/shm is drwxrwxrwt) and finally a kind of splash screen is displayed (which is grey actually) and it stops there... Is that the normal behaviour?

@bennlich
Copy link

@raphaelbastide See my new edit(Solved) in the description. Should also work for you

Works perfectly, thank you @danrobi11. Do you know what this command does?

Some discussion here: https://security.stackexchange.com/questions/209529/what-does-enabling-kernel-unprivileged-userns-clone-do

@j75
Copy link

j75 commented May 8, 2021

No, I have the same issue on Ubuntu 20.04.02 regardless the value of kernel.unprivileged_userns_clone!
The application tries to start, a gray splashscreen is shown, but stops there! The latest messages are

...
{"category":"hyper","subcategory":"daemon"}
info:     Daemon: Running hyperspace/3.15.0 linux-x64 node-v12.18.3
 {"category":"hyper","subcategory":"daemon"}
info:     Daemon: Listening on /tmp/hyperspace.sock
 {"category":"hyper","subcategory":"daemon"}
info:     Daemon: Remote client opened
 {"category":"hyper","subcategory":"daemon"}
info:     Hyperdrive daemon has been restored {"category":"hyper","subcategory":"daemon"}
info:     Initialized dat daemon {"category":"hyper","subcategory":"drives"}
info:     Initializing hyperdrive filesystem {"category":"browser","subcategory":"init"}
info:     Loading root drive {"category":"hyper","subcategory":"filesystem","url":"hyper://383b..85/"}
info:     Initializing browser {"category":"browser","subcategory":"init"}
info:     Registering protocols {"category":"browser","subcategory":"init"}
info:     Running setup flow {"category":"browser","subcategory":"init"}
[2248901:0508/223309.899052:FATAL:platform_shared_memory_region_posix.cc(255)] This is frequently caused by incorrect permissions on /dev/shm.  Try 'sudo chmod 1777 /dev/shm' to fix.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants