beaker
beaker copied to clipboard
beakerbrowser
Appimage needs `--no-sandbox` set during build in order to start (Solved)
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
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
$ ./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
$ ./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
Oof, this is a bummer. Related issues:
- https://github.com/nklayman/vue-cli-plugin-electron-builder/issues/433
- https://github.com/electron-userland/electron-builder/issues/3872
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.
I just tested the snap v0.8.10 works perfectly and does sync with hashbase without having to restart beaker.
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)
@raphaelbastide See my new edit(Solved) in the description. Should also work for you
@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?
@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
@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. :laughing:
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:
-
GoogleBooks Google Chrome on why they sandbox. It's in images with a small/medium/large viewing option at top right corner.
-
Google Chrome sandboxing feature: " --no-sandbox" switch where a member very simply says:
The sandbox is the "stealth" browsing technology. If you're not concerned with that, then, no big deal.
hm :smile:
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?
@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
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.