ipfs-desktop > Trace/breakpoint trap

[commandline-be]

installed from latest .deb on a debian derivate

on launch
$ipfs-desktop
$Trace/breakpoint trap

[alphanmoon]

The same issue on Debian 10 after .deb install:
$ipfs-desktop
$Trace/breakpoint trap

And it's not starting from inside the xfce app menu.

[nekr0z]

Yep, I confirm on Debian 10.

[autonome]

Thanks for reporting, looking asap!

[lidel]

I believe it is the same problem as described in signalapp/Signal-Desktop#3536.

IUUC this needs to be fixed in electron-builder responsible for creating .deb.
I've added this to v0.10.4 (#1343)

For now, available workarounds are:

• Run with additional parameter:
  ipfs-desktop --no-sandbox
  • This is what Signal does on Debian 10 too: /opt/Signal/chrome-sandbox gets installed with 0755 instead of 4755 on Debian. signalapp/Signal-Desktop#3627 (comment)
• If you don't feel safe with that, you have two options:
  • enable user namespaces for unprivileged users by setting sysctl kernel.unprivileged_userns_clone=1
  • wrap execution in something like Firejail: firejail ipfs-desktop --no-sandbox

@commandline-be @alphanmoon @nekr0z
Let me know if any of this helped. If not, please share the output of uname -a

[commandline-be]

Thanks for the very informative response. 😁 I already hope for a rewrite in rust so this sandbox nonsense can be left behind.

[lidel]

Nonsense indeed.. I hoped for a generic fix, but Chrome/Electron sandbox situation on Linux is nearly as bad as the tray icon one (#1153) 🙃

Below is my brain dump. TL;DR: fix is in #1370

---

As noted in ssbc/patchwork#1217 (comment) and 99999 issues about --no-sandbox one can find on github, nobody seems to agree how to handle this mess.

• Debian: Disallow unprivileged CLONE_NEWUSER by default
• Electron/Chromium: Depend on unprivileged CLONE_NEWUSER or root SUID on chrome-sandbox, discourage --no-sandbox

Ugh.. ok. Even if we ignore security considerations of SUID and are okay with going that route... we can't. Not everywhere:

• AppImage / Snap: Reject packages with root SUID
  (Packaging Electron v5+ with sandbox (AppImage)  electron-userland/electron-builder#4495, Snapcraft review fails electron-userland/electron-builder#3608)

So.. what are our options given we are bound to Electron and electron-builder?

• I've seen folks hack around it by reimplementing linux packaging in sequential manner, setting setuid flags on everything linux related apart from appimage and snap
  (example in ElectronMail repo)
  • We have no bandwidth for writing nor maintaining that type of Rube Goldberg machine, and I am not sure if that is even the right thing to do in the first place. What If setuid hack is removed and all this work is for nothing?
• Best we can do for now is to set executableArgs to --no-sandbox in electron-builder.yml.
  • Done just that in fix: startup on Debian 10 #1370 + updated deps where possible
  • This fixes GUI: will update Exec command in ipfs-desktop.desktop manifest that is run when menu item / icon in desktop environment is clicked.
  • CLI users can always add --no-sandbox manually – will update README.

[lidel]

Hi friends, fyi v0.10.4 shipfs with updated ipfs-desktop.desktop manifest which starts ipfs-desktop with --no-sandbox by default, restoring startup via GUI shortcut on Debian 10.