debian 10 main
A number of appimages programs used to start. Now they do not. Maybe
it is due to an update of debian. I cannot tell.
Starting several appimages from command line returns:
‘some numbers’ 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_DeltaCm3TGjB/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap
For instance jitsi-meet-x86_64.AppImage and DeltaChat-1.22.2.AppImage return the above
message. krita-5.0.0-x86_64.appimage starts. What is this about? If updating the
debian packages resulted in the before mentioned error message, why would that
be so? Isn’t an appimage autonomous such that in most cases a program will
start anyway? Thank you.
AppImages based on Electron require the kernel to be configured in a certain way to allow for its sandboxing to work as intended (specifically, the kernel needs to be allowed to provide “unprivileged namespaces”). Many distributions come with this configured out of the box (like Ubuntu for instance), but some do not (for example Debian).
To temporarily enable unprivileged namespaces, you can run this command:
sudo sysctl -w kernel.unprivileged_userns_clone=1
This command will take effect immediately but will not survive a reboot. To permanently enable unprivileged namespaces, run:
echo kernel.unprivileged_userns_clone = 1 | sudo tee /etc/sysctl.d/00-local-userns.conf
This command will take effect only on the next reboot.
Please see https://docs.appimage.org/user-guide/troubleshooting.html#i-have-issues-with-electron-based-appimages-and-their-sandboxing for more information.
If you think that Debian should enable unprivileged namespaces by default (like most other desktop distributions do), then please file an issue with Debian.
some do not (for example Debian).
Has debian made that decision for security
or privacy reasons?
Don’t know - that would be a question you’d need to ask Debian developers. I would not be surprised if they would cite “security”. But then, Ubuntu isn’t known for being insecure just because they configured this stuff to “just work” out of the box…
Enabling unprivileged user namespaces makes exploiting the linux kernel “easier.” Canonical/Red Hat/et al can “squash” a bunch of exploit chains by changing that default option in their distros.
There’s a huge amount of resources dedicated to this topic compiled at linux - What does enabling kernel.unprivileged_userns_clone do? - Information Security Stack Exchange from various reputable sources (LWN/Brad Spengler/Project Zero/seclists.org/Rapid7/…)
Disabling unprivileged user namespaces makes Chromium/Electron based applications require a suid helper binary. Those are also not exactly good for security, especially if you distrust Google.