AppImage executable won't launch

[Mukund-Bhardwaj]

Bug Description:

AppImage executable won't launch without disabling sandboxing.
Application works completely find after adding --no-sandbox command line argument
The following error is shown in the terminal:

[184044:0610/211014.832520: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_TheiaI98fe20/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)

Steps to Reproduce:

1. Give executable permission to the AppImage file
2. Run the executable via terminal

Additional Information

• Operating System: Kubuntu 24.04
• Theia Version: 1.49

[jfaltermeier]

Thank you for the report. Sounds like this: https://docs.appimage.org/user-guide/troubleshooting/electron-sandboxing.html
We may try https://www.npmjs.com/package/electron-builder-sandbox-fix

[otherpaco]

@jfaltermeier, that seems not to be the problem.

I use Ubuntu 24.04. and have the same problem.

sysctl kernel.unprivileged_userns_clone returns
kernel.unprivileged_userns_clone = 1

So no need for the sandbox-fix package.

But I found this:

The issue comes from Ubuntu 24.04 deprecating unprivileged kernel namespaces, which the Arduino IDE (and other applications) rely on for their sandboxes.

From a sandbox problem with the Arduino IDE discussed on askubuntu, here the corresponding github issue

The workaround ./TheiaIDE.AppImage --no-sandbox works but you loose the security of a sandbox.

[sgraband]

I will take a look.

[JonasHelming]

@sgraband Is this related to #377 maybe?

[sgraband]

Unfortunately, I haven't had much time to look into this. Hopefully i can do so this week. Will take a look if they are related.

[hklene]

The way forward seems to be an AppArmor profile for each electron-based AppImage:
arduino/arduino-ide#2429 (comment)

Question is, how to get it included with Ubuntu for them to ship it same as they already do for vscode (so that not each and everyone has to hack those exceptions herself)?

$ cat /etc/apparmor.d/code
# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"

abi <abi/4.0>,
include <tunables/global>

profile vscode /usr/share/code{/bin,}/code flags=(unconfined) {
  userns,

  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/code>
}

[tuxPM]

Question is, how to get it included with Ubuntu for them to ship it same as they already do for vscode (so that not each and everyone has to hack those exceptions herself)?

Indeed, the problem is that AppImage can be placed anywhere by the user. So apparmor file should be updated each time file is moved.

Anyway, I confirm that adding the file on ubuntu 24.04, fix the issue.

I put all theia versions in /opt/theira/

and created this file in /etc/apparmor.d/opt.theia

abi <abi/4.0>,

include <tunables/global>

profile theia /opt/theia/* flags=(unconfined) {

  userns,

  include if exists <local/theia>
} 

[sgraband]

Thank you @hklene & @tuxPM for the workaround. As far as i understand, this is a common issue for all electron apps running in sandbox mode from Ubuntu 24.04 going forward. This is also indicated by AppArmor shipping the same workaround for most of the applications.
For short term help i would suggest to link this issue in the troubleshooting section of the README. Long term we should investigate if it makes more sense to focus on a *.deb package where we can control the installation folder and ship the workaround with it (or add the workaround for the Theia IDE to the default AppArmor profiles). Like you already mentioned the issue with the AppImage is that it can be placed anywhere by the user.

[tsmaeder]

Strangely, when you install the VS Code snap package, the command in /snap/code/current/meta/snap.yml reads

command: electron-launch $SNAP/usr/share/code/bin/code --no-sandbox

It looks like starting with --no-sandbox seems acceptable to the VS Code folks. On can argue that the sandbox is to guard against unsafe content loaded from the internet, which is not something VS Code and Theia don't generally do, unlike a browser.

[tsmaeder]

One idea I've had would be to detect the sandbox problem and to output a message asking to the user to run theia with "--no-sandbox" and maybe a link to some documentation that describes the issue.
I think the normal use case should be that we have a privileged installer that can install the proper app armor profile. If people want to run a portable install (for example if they just want to try out Theia and don't have privileges on their corporate machine) adding a startup parameter seems acceptable to me.

[xai]

@tsmaeder, @jfaltermeier, and I briefly discussed this. Here is a summary of some thoughts that we had:

Regarding the application failing to start on Ubuntu 24.04 due to the user namespace issue:

• We feel that --no-sandbox is acceptable for an IDE. My bash and my vi process are also not sandboxed, and while this might, of course, also be improved, I don't feel very unprotected because of that 😄
  The scenario would be different for a browser or an Electron instance fetching untrusted data from the web.
• The "workaround" currently suggested by the AppImage when it fails ("You need to make sure that /home/user/.../node_modules/electron/dist/chrome-sandbox is owned by root and has mode 4755.") sounds really really wrong, so making that go away with a warning to use --no-sandbox would be an improvement already.
• deb package (currently not really advertised to users due to the lack of an update site): In our .deb package, we could easily include an AppArmor profile in /etc/apparmor.d/ that allows userns for the executable as an alternative to --no-sandbox.
• snapstore: We need to verify how the snap behaves on Ubuntu 24.04 and whether we need to adjust anything there as well.

Regarding preferred installation source for users:

• While the now available snap is probably the most convenient way for Ubuntu/Debian users to consume Theia-IDE, we should continue providing alternatives for users who cannot or do not want to use snapd. As we probably do not have the resources to package and maintain installations for every distro/version out there, it seems logical to keep the AppImage as an equivalent and simple installation source for users without snapd or sudo rights.

[JonasHelming]

Ok, in terms of actions, should we:

• Make the snap version more visible
• Add --no-sandbox to the AppImage version (only)
  ?

[tsmaeder]

@JonasHelming that's the idea, yes.

[JonasHelming]

OK I will do the frst item, @sgraband Can you add --no-sandbox to the AppImage version and let me know when its done?

[JonasHelming]

see: eclipse-theia/theia-website#636

[sgraband]

@JonasHelming i opened #414 for this.

[hklene]

The snap install asks right now:

My translation:

This snap-application is not compatible with the security-sandbox and has full access to your computer. Install anyway?

My gut feeling is, that an app-armor-profile installed by a deb is less off-putting ...

At least I suggest concocting and linking an easy language FAQ-article landing page explaining the issue and deeplinking some more background of what other options exist.

-- edit --
Found another interesting post on the background of this:
laurent22/joplin#10332 (comment)
logseq/logseq#11240 (comment)
electron/electron#41066
https://bugs.launchpad.net/apparmor/+bug/2046844/comments/12
https://bugs.launchpad.net/apparmor/+bug/2046844/comments/37

[xai]

My gut feeling is, that an app-armor-profile installed by a deb is less off-putting ...

👍
After being a Debian user for over twenty years myself, I would always prefer a well-maintained and signed deb source to an AppImage or a snap from a user perspective. Even more so from a sysadmin perspective!

The problem with our current deb is that, IMHO, we currently do not have a maintained update site (that we could also offer as a reliable sources.list entry to users), so the non-fulfilled update scenario is currently the main obstacle to pushing the deb more prominently. Having users that cannot easily upgrade is worse than using snap or having self-updating appimages, especially but not only from a security point of view. So, having an eclipse-foundation-hosted Debian repo providing up-to-date packages for, e.g., amd64 would be an interesting option for Debian-based distros and their users.

[sgraband]

@hklene You have an ubuntu 24.04 system, is that right? If yes, could you maybe tryout my fix proposed in #414 (contains building instructions) and let us know, if that fixes the issues for the AppImage? Thanks in advance